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12 GroupWise 8 Interoperability Guide 


About This Guide 


This Novell GroupWise 8 Interoperability Guide helps you use GroupWise in the context of other 
software products. The guide provides assistance with Novell products and third-party products: 


Novell Products + Part, “Novell Cluster Services on NetWare,” on page 15 
+ Part Il, “Novell Cluster Services on Linux,” on page 117 
+ Part Ill, “Novell Vibe,” on page 231 
+ Part IV, “Novell Conferencing,” on page 243 
+ Part V, “Novell ZENworks,” on page 249 
+ Part VI, “Other Novell Products,” on page 269 


Third-Party Products + Part VII, “Microsoft Clustering Services on Windows,” on page 279 
+ Part VIII, “Non-GroupWise E-Mail Clients,” on page 345 
+ Part IX, “Mobile Devices,” on page 355 


For information about additional GroupWise-related software from GroupWise partners, see the 
Novell Partner Product Guide (http://www.novell.com/partnerguide). 


For troubleshooting assistance, see: 


* GroupWise 8 Troubleshooting 1: Error Messages 

+ GroupWise 8 Troubleshooting 2: Solutions to Common Problems 

+ GroupWise 8 Troubleshooting 3: Message Flow and Directory Structure 

+ Novell Support and Knowledgebase (http://www.novell.com/support) 


To search the GroupWise documentation from the Novell Support Web site, click Advanced 
Search, select Documentation in the Search In drop-down list, select GroupWise in the Products 
drop-down list, type the search string, then click Search. 


+ GroupWise Support Forums (http://forums.novell.com/forumdisplay.php? &f=356) 
+ GroupWise Support Community (http://www.novell.com/support/products/groupwise) 


+ GroupWise Cool Solutions (http://www.novell.com/coolsolutions/gwmag/index.html) 


Audience 


This guide is intended for network administrators who install and administer GroupWise. 


Feedback 


We want to hear your comments and suggestions about this manual and the other documentation 
included with this product. Please use the User Comment feature at the bottom of each page of the 
online documentation, or go to Novell Documentation Feedback (http://www.novell.com/ 
documentation/feedback.html) and enter your comments there. 
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Additional Documentation 


For additional GroupWise documentation, see the following guides at the Novell GroupWise 8 
documentation Web site (http://www.novell.com/documentation/gw8): 


¢ Installation Guide 

+ Administration Guide 

+ Multi-System Administration Guide 

¢ Troubleshooting Guides 

+ GroupWise Client User Guides 

+ GroupWise Client Frequently Asked Questions (FAQ) 
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| Novell Cluster Services on NetWare 


+ Chapter 1, “Introduction to GroupWise 8 and Novell Cluster Services on NetWare,” on page 17 
¢ Chapter 2, “Planning GroupWise in a NetWare Cluster,” on page 19 

¢ Chapter 3, “Setting Up a Domain and Post Office in a NetWare Cluster,” on page 39 

+ Chapter 4, “Implementing the Internet Agent in a NetWare Cluster,” on page 63 

¢ Chapter 5, “Implementing WebAccess in a NetWare Cluster,” on page 81 

+ Chapter 6, “Implementing GroupWise Gateways in a NetWare Cluster,” on page 97 

¢ Chapter 7, “Monitoring a GroupWise System in a NetWare Cluster,” on page 99 

+ Chapter 8, “Backing Up a GroupWise System in a NetWare Cluster,” on page 101 

¢ Chapter 9, “Updating a GroupWise System in a NetWare Cluster,” on page 103 

+ Chapter 10, “Moving an Existing GroupWise 8 System into a NetWare Cluster,” on page 105 
¢ Chapter 11, “Implementing Messenger in a NetWare Cluster,” on page 107 
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Introduction to GroupWise 8 and Novell 
Cluster Services on NetWare 


Before implementing GroupWise 8 with Novell Cluster Services, make sure you have a solid 
understanding of Novell Cluster Services by reviewing the following information resources: 


+ AppNote: An Introduction to Novell Cluster Services (http://developer.novell.com/research/ 
appnotes/1999/may/01/a990501_.pdf) 


+ Novell Open Enterprise Server (OES) Product Documentation: OES Novell Cluster Services 1.8 
Administration Guide for NetWare (http://www.novell.com/documentation/oes/cluster_admin/ 
data/h4hgu4hs.html#bktitle) 


+ NetWare 6.5 Product Documentation: Novell Cluster Services (http://www.novell.com/ 
documentation/ncs65) 


When you review the information resources recommended above, you discover that clustering 
employs very specialized terminology. The following brief glossary provides basic definitions of 
clustering terms and relates them to your GroupWise system: 


cluster: A grouping of from 2 to 32 NetWare servers configured using Novell Cluster Services so that 
data storage locations and applications can transfer from one server to another without interrupting 
their availability to users. 


node: A clustered server; in other words, a single NetWare server that is part of a cluster. 


resource: An IP address, volume, application, service, and so on, that can function successfully 
anywhere in the cluster. The volumes where domains and post offices reside are a specific type of 
cluster resources termed “volume resources.” In this section, the terms “cluster resource” and 
“volume resource” are used instead of “resource” to avoid confusion with GroupWise resources 
(such as conference rooms and projectors). 


failover: The process of moving cluster resources from a failed node to a functional node so that 
availability to users is uninterrupted. For example, if the node where the POA is running goes down, 
the POA and its post office fail over to a secondary node so that users can continue to use GroupWise. 
When setting up cluster resources, you need to consider what components need to fail over together 
in order to continue functioning. 


fan-out-failover: The configuration where cluster resources from a failed node fail over to different 
nodes in order to distribute the load from the failed node across multiple nodes. For example, if a 
node runs a cluster resource consisting of a domain and its MTA, another cluster resource consisting 
of a post office and its POA, and a third cluster resource for WebAccess, each cluster resource can be 
configured to fail over separately to different secondary nodes. 


failback: The process of returning cluster resources to their preferred node after the situation causing 
the failover has been resolved. For example, if a POA and its post office fail over to a secondary node, 
that cluster resource can be configured to fail back to its preferred node when the problem is 
resolved. 
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migration: The process of manually moving a cluster resource from its preferred node to a secondary 
node for the purpose of performing maintenance on the preferred node, temporarily lightening the 
load on the preferred node, and so on. 


shared disk system: The hardware housing the physical disk volumes that are shared among the 
cluster nodes. 


shared volume: A volume in a shared disk system that can be accessed from any cluster node that 
needs the data stored on it. 


cluster-enabled shared volume: A shared volume for which a Volume Resource object has been 
created in Novell eDirectory. The properties of the Volume Resource object provide load and unload 
scripts for programs installed on the volume, failover/failback/migration policies for the volume, and 
the failover path for the volume. Cluster-enabling is highly recommended for GroupWise. 


GroupWise volume: As used in this section, a cluster-enabled shared volume that is used for 
GroupWise, such as for storing a domain, post office, software distribution directory, and so on. This 
section also uses the terms Internet Agent volume, WebAccess Agent volume, Messenger volume, 
and gateway volume in a similar manner. 


storage area network (SAN): The cluster nodes together with their shared disk system and shared 
volumes. 


virtual server: A logical server, rather than a physical server, to which cluster-enabled shared 
volumes are tied. 


active/active mode: The configuration of a clustered application where the application runs 
simultaneously on multiple nodes in the cluster. Active/active mode is recommended when the 
GroupWise MTA, POA, Internet Agent, and WebAccess Agent run in protected memory because 
protected memory isolates them from each other, even if they are running on the same node. 


active/passive mode: The configuration of a clustered application where the application runs on only 
one node at a time in the cluster. The GroupWise MTA, POA, Internet Agent, and WebAccess Agent 
must run in active/passive mode if they are not running in protected memory because only one 
instance of each agent/database combination can be running at the same time in the cluster. 
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Planning GroupWise in a NetWare 
Cluster 


The majority of this part of the GroupWise 8 Interoperability Guide (Chapter 2, “Planning GroupWise in 
a NetWare Cluster,” on page 19 through Chapter 8, “Backing Up a GroupWise System in a NetWare 
Cluster,” on page 101) is designed for those who are creating a new GroupWise system, or at least 
new domains and post offices, in the context of Novell Cluster Services. If you already have an 
existing GroupWise 8 system and need to configure it to work in a newly installed cluster, see 
Chapter 10, “Moving an Existing GroupWise 8 System into a NetWare Cluster,” on page 105. 


When you implement a new GroupWise system or a new domain or post office in a clustering 
environment, overall GroupWise system design does not need to change substantially. For a review, 
see “Installing a Basic GroupWise System” in the GroupWise 8 Installation Guide. However, the 
configuration of individual components of your GroupWise system will be significantly different. 
This section helps you plan the following GroupWise components in a cluster: 

+ Anew GroupWise system consisting of the primary domain and the initial post office 

+ Anew secondary domain 

+ Anew post office 

+ The GroupWise agents (MTA and POA) 
During the planning process, component configuration alternatives are explained. For example, you 
might want the domain and post office together on the same shared volume or on different shared 
volumes. You might want to install the agents to standard sys: \system directories or to manually 


created vol: \system directories on shared volumes where domains and post offices reside. You 
might or might not need to run the agents in protected memory. 


The “System Clustering Worksheet” on page 33 lists all the information you need as you set up 
GroupWise in a clustering environment. You should print the worksheet and fill it out as you 
complete the tasks listed below: 

+ Section 2.1, “Meeting Software Version Requirements,” on page 20 

+ Section 2.2, “Installing Novell Cluster Services,” on page 20 

è Section 2.3, “Planning a New Clustered Domain,” on page 21 

+ Section 2.4, “Planning a New Clustered Post Office,” on page 22 

è Section 2.5, “Planning a New Library for a Clustered Post Office,” on page 23 


+ Section 2.6, “Deciding Whether to Cluster-Enable the Shared Volumes Used by GroupWise,” on 
page 23 


+ Section 2.7, “Ensuring Successful Name Resolution for GroupWise Volumes,” on page 25 
+ Section 2.8, “Deciding How to Install and Configure the Agents in a Cluster,” on page 26 
+ Section 2.9, “GroupWise Clustering Worksheets,” on page 32 
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2.1 


2.2 


After you have completed the tasks and filled out “System Clustering Worksheet” on page 33, you 
are ready to continue with Chapter 3, “Setting Up a Domain and Post Office in a NetWare Cluster,” 
on page 39. 


Meeting Software Version Requirements 


GroupWise 8 can be clustered on a system that meets the following requirements: 


O GroupWise 8 
O A supported version of NetWare with the latest Support Pack 


OES NetWare 
+ NetWare 6.5 


IMPORTANT: Novell Cluster Services does not support mixed NetWare versions within a cluster. 





SYSTEM CLUSTERING WORKSHEET 


Under Item 1: Software Version Updates for Cluster, mark any updates required for nodes in the 
cluster to ensure that all nodes in the cluster are running the same version of NetWare. 


Installing Novell Cluster Services 


Install Novell Cluster Services by following the instructions provided in the documentation for your 
version of NetWare, as listed in Chapter 1, “Introduction to GroupWise 8 and Novell Cluster Services 
on NetWare,” on page 17. 


The installation process includes: 
+ Meeting hardware and software requirements 
+ Setting up a shared disk system 
+ Creating a new NetWare Cluster object to represent the cluster in Novell eDirectory 
+ Adding nodes to the cluster 
¢ Installing the Novell Cluster Services software on all nodes in the cluster 


+ Mounting the shared volumes where you will set up GroupWise domains and post offices and 
install the GroupWise agents 


As you install Novell Cluster Services, record key information about the cluster on the System 
Clustering Worksheet: 


SYSTEM CLUSTERING WORKSHEET 


Under Item 2: eDirectory Tree for Cluster, record the name of the eDirectory tree where the new 
NetWare Cluster object has been created. 


Under Item 3: Cluster Name, record the name of the NetWare Cluster object that you created for your 
GroupWise system. 


Under Item 4: Cluster Context, record the full context of the NetWare Cluster object. 


Under Item 5: Nodes in Cluster, list the nodes that you have added to the cluster. 
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2.3 


The number of nodes and shared volumes that are available in the cluster strongly influences where 
you place GroupWise domains and post offices. You have several alternatives: 


¢ Your whole GroupWise system can run in a single cluster. 


+ Parts of your GroupWise system can run in one cluster while other parts of it run in one or more 
other clusters. 


¢ Parts of your GroupWise system can run in a cluster while other parts run outside of the cluster, 
on non-clustered servers. 


If you do not have the system resources to run all of your GroupWise system in a clustering 
environment, you must decide which parts have the most urgent need for the high availability 
provided by clustering. Here are some suggestions: 


+ Post offices and their POAs must be available in order for users to access their GroupWise 
mailboxes. Therefore, post offices and their POAs are excellent candidates for the high 
availability provided by clustering. 


+ Ina like manner, WebAccess provides user access to GroupWise mailboxes across the Internet 
through users’ Web browsers. It is another good candidate for clustering. 


+ Domains and their MTAs are less noticeable to users when they are unavailable (unless users in 
different post offices happen to be actively engaged in an e-mail discussion when the MTA goes 
down). On the other hand, domains and their MTAs are critical to GroupWise administrators, 
although administrators might be more tolerant of a down server than end users are. Critical 
domains in your system would be the primary domain and, if you have one, a hub or routing 
domain. These domains should be in the cluster, even if other domains are not. 


¢ The Internet Agent might or might not require high availability in your GroupWise system, 
depending on the importance of immediate messaging across the Internet and the use of POP3 
or IMAP4 clients by GroupWise users. 


There is no right or wrong way to implement GroupWise in a clustering environment. It all depends 
on the specific needs of your particular GroupWise system and its users. 


Planning a New Clustered Domain 


The considerations involved in planning a new domain in a clustering environment are essentially 
the same as for any other environment. 


¢ Primary Domain: If you are setting up a new GroupWise system in a clustering environment, 
you will be creating the primary domain as you complete the tasks in this section. In 
preparation, review “Planning a Basic GroupWise System”, then print and fill out the “Basic 
GroupWise System Summary Sheet” in “Installing a Basic GroupWise System” in the GroupWise 
8 Installation Guide. This covers planning the primary domain and an initial post office in the 
primary domain. 


+ Secondary Domain: If your GroupWise system already exists, you will be creating a new 
secondary domain. In preparation, review “Planning a New Domain”, then print and fill out the 
“Domain Worksheet” in “Domains” in the GroupWise 8 Administration Guide. 
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2.4 


Regardless of the type of domain you are creating, keep in mind the following cluster-specific details 
as you fill out the worksheet you need: 


¢ When you specify the location for the domain directory (and for a new GroupWise system, the 
post office directory) on the worksheet, include the shared volume where you want the directory 
to reside. 


+ Do not concern yourself with the GroupWise agent information on the worksheet. You will plan 
the agent installation later. If you are filling out the Basic GroupWise System Worksheet, stop 
with Post Office Settings. If you are filling out the Domain Worksheet, stop with Domain 
Administrator. 


When you have completed the worksheet, transfer the key information from the Basic GroupWise 
System Worksheet or the Domain Worksheet to the System Clustering Worksheet. 
SYSTEM CLUSTERING WORKSHEET 


Under Item 10: Domain Name, transfer the domain name and database directory to the System 
Clustering Worksheet. 


Under Item 7: Shared Volume for Domain, transfer the domain location to the System Clustering 
Worksheet. You will fill out the rest of the information under item 7 later. 


IMPORTANT: Do not create the new domain until you are instructed to do so in Chapter 3, “Setting 
Up a Domain and Post Office in a NetWare Cluster,” on page 39. 





Planning a New Clustered Post Office 


The considerations involved in planning a new post office in a clustering environment are essentially 
the same as for any other environment. The initial post office in a new GroupWise system is planned 
on the Basic GroupWise System Worksheet. To plan additional new post offices, review “Planning a 
New Post Office ”, then print and fill out the “Post Office Worksheet” in “Post Offices” in the 
GroupWise 8 Administration Guide. When you specify the locations for the post office directories, 
include the shared volumes where you want the post office directories to reside. 


When you have completed the worksheet, transfer key information from the Basic GroupWise 
System Worksheet or the Post Office Worksheet to the System Clustering Worksheet. 


SYSTEM CLUSTERING WORKSHEET 


Under Item 11: Post Office Name, transfer the post office name and database location to the System 
Clustering Worksheet. 


If you will create the post office on a different shared volume from where the domain is located, under 
Item 8: Shared Volume for Post Office, transfer the post office location to the System Clustering 
Worksheet. You will fill out the rest of the information under item 8 later. 





IMPORTANT: Do not create the new post office until you are instructed to do so in Chapter 3, 
“Setting Up a Domain and Post Office in a NetWare Cluster,” on page 39. 
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2.6 


Planning a New Library for a Clustered Post Office 


The considerations involved in planning a new library in a clustering environment are essentially the 
same as for any other environment. You can plan a library for a clustered post office by following the 
standard instructions provided in “Creating and Managing Libraries” in the GroupWise 8 
Administration Guide and filling out the “Basic Library Worksheet” or the “Full-Service Library 
Worksheet”. Then provide the library information on the System Clustering Worksheet. 


SYSTEM CLUSTERING WORKSHEET 


Under Item 14: Library Location, mark where you want to create the library's document storage area. 


If the document storage area will be located outside the post office directory structure, specify a user 
name and password that the POA can use to access the volume where the document storage area 
will reside. 





IMPORTANT: Do not create the new library until you are instructed to do so in Chapter 3, “Setting 
Up a Domain and Post Office in a NetWare Cluster,” on page 39. 





Deciding Whether to Cluster-Enable the Shared Volumes 
Used by GroupWise 


Cluster-enabling the shared volumes where domains and post offices reside greatly simplifies 
GroupWise administration. If you are creating a new GroupWise system, you might also want to 
cluster-enable shared volumes for the GroupWise administration snap-ins to ConsoleOne and for the 
GroupWise software distribution directory so that these locations are always available within the 
cluster. To review the concept of cluster-enabled shared volumes, see the applicable section of 
clustering documentation for your version of NetWare, as listed in Chapter 1, “Introduction to 
GroupWise 8 and Novell Cluster Services on NetWare,” on page 17. 


The advantages of cluster-enabling GroupWise volumes include: 


¢ Drive mappings always occur through the virtual server associated with the cluster-enabled 
volume, rather than through a physical server. This guarantees that you can always map a drive 
to the domain or post office database no matter which node it is currently located on. 


+ The GroupWise snap-ins to ConsoleOne always work no matter which node is running 
ConsoleOne. 


+ Cluster-enabling the domain volume and installing the GroupWise agents to this volume 
guarantees that the GroupWise snap-ins to ConsoleOne can always find the configuration files 
that they need to access. 


+ When you rebuild a domain database or a post office database, you do not need to determine 
which node the database is currently located on. 


¢ Help desk personnel do not need to be trained to determine where GroupWise is running before 
they connect to a domain to create a new GroupWise user. 


When you cluster-enable a volume, additional eDirectory objects are created: 
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Table 2-1 eDirectory Objects Used in a Cluster 


eDirector 

y Object Name and Description 

Object 

B clustername_volumename (default object name) 
A new Volume object represents the cluster-enabled volume. It is created by renaming 
the original Volume object that was tied to a physical server and associating it with a 
virtual server instead. 
For example, if your cluster name is GWCLUSTER and your original volume name is 
gwvol1, the new Volume object representing the cluster-enabled volume is named 
gwcluster_gwvol1. 

Si clustername_volumename_SERVER (default object name) 
A new Server object represents the virtual server to which the new cluster-enabled 
volume is tied. 
Continuing with the above example, the new Server object representing the virtual server 
is named GWCLUSTER_GWVOL1_SERVER. 

ap volumename_SERVER.clustername (default object name) 
A new Volume Resource object stores property information for the cluster-enabled 


volume, such as start, failover, and failback mode information and load/unload scripts. 
These modes and scripts enable the cluster-enabled volume to function much like an 
independent server; hence, the SERVER portion of its name. The Volume Resource 
object is created in the Cluster container object. 


Continuing with the above example, the new Volume Resource object is named 
GWVOL1_SERVER.GWCLUSTER. 





IMPORTANT: Notice that the default object names include the underscore (_) character. Some DNS 
name servers cannot resolve object names that include underscore characters. If you have met the 
system requirements described in Section 2.1, “Meeting Software Version Requirements,” on page 20, 
you can rename these objects as needed when you cluster enable the volume. 





Cluster-enabling the shared volumes used by GroupWise is highly recommended. Throughout the 
rest of this document, the term “GroupWise volume” means “a cluster-enabled shared volume used 
by GroupWise.” 


SYSTEM CLUSTERING WORKSHEET 


Under Item 6: Shared Volumes for GroupWise Administration, list any shared volumes you want to 
use for GroupWise administration purposes. For example, you might have a shared pub: volume with 
a public directory where you install the GroupWise snap-ins to ConsoleOne instead of installing them 
on multiple administrator workstations. You might have a shared apps: volume where you create the 
GroupWise software distribution directory. Mark whether or not you want to cluster-enable the 
GroupWise administration volumes. 


Under Item 7: Shared Volume for Domain, specify the name of the shared volume where you will 
create the domain. Mark whether or not you want to cluster-enable the domain volume. Also mark 
whether you will place the post office on the same volume with the domain. 


If you want the post office on a different volume from where the domain is located, under Item 8: 
Shared Volume for Post Office, specify the name of the shared volume where you will create the post 
office. Mark whether or not you want to cluster-enable the post office volume. 
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IMPORTANT: Because cluster-enabling the volumes where domains and post offices reside is so 
strongly recommended, this documentation does not include the steps for setting up domains and 
post offices on non-cluster-enabled volumes. If you decide not to cluster-enable GroupWise volumes, 
you should adjust the steps presented in this documentation for your system’s specialized needs. 
Novell Cluster Services does provide a GroupWise Mail Server template for use when creating 
GroupWise Cluster Resource objects instead of cluster-enabled Volume Resource objects. 


Ensuring Successful Name Resolution for GroupWise 
Volumes 


Because you are using cluster-enabled volumes for GroupWise domains and post offices, you must 
ensure that short name resolution is always successful. For example, in ConsoleOne, if you right-click 
a Domain object in the GroupWise View and then click Connect, ConsoleOne must be able to resolve 
the domain database location, as provided in the UNC Path field, to the network address of the 
current, physical location of that domain within your cluster. It is through short name resolution that 
all GroupWise cluster resources (such as domain and post office volumes) are accessed and managed 
in ConsoleOne. 


A client program (such as ConsoleOne) that runs on a Windows workstation, can be configured to 
use several different short name resolution methods. To see which methods are in use at a particular 
workstation, view the protocol preferences for the Novell Client that is installed on the Windows 
workstation: 


Figure 2-1 Novell Client Preferences Property Page 


Novell Client for Windows 2000 Properties a 2 x] 


Single Sign-on | DHCP Settings | Default Capture | 
Advanced Settings | Advanced Menu Settings | 
Client | Location Profiles | Advanced Login | Contextless Login | 
Protocol Preferences | Service Location | 


Select a protocol and component to configure 


Preferred Network Protocol: x 


Protocol: Component: 


—— 


Protocol component settings - J 
MINDS 
| Host File 





Short name resolution methods that pertain to clustering your GroupWise system are discussed 
below: 
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Table 2-2 Short Name Resolution Methods 


Short 
Name 
Resolution 
Method 


eDirectory 


Hosts File 


DNS 


SLP 


Description 


You can use eDirectory to resolve short names into specific network addresses. However, 
when using eDirectory for short name resolution, you must remember to consider current 
context in the name resolution process. eDirectory short name resolution works only if 
your current context is the same as the context of the eDirectory object you need to 
access. 


Windows uses the following files when performing short name resolution at the 
workstation: 


+ Windows XP\Vista: 
\winnt\system32\drivers\etc\hosts 


Using these files at the Windows workstation is not a preferred method for TCP/IP name 
resolution (except perhaps for the administrator’s workstation). 


However, whenever you cluster-enable a volume, you should add its virtual server to the 
sys: \etc\hosts file of all nodes in the cluster. 


Perhaps the most common short name resolution option is Domain Name Service (DNS). 
As with the hosts file, it is good practice to place all of your virtual servers into DNS. 


For short name resolution to work using DNS, the client workstation must either belong to 
the same DNS zone (such as provo.novell.com) as the cluster resource, or the cluster 
resource zone must be configured in the client's DNS suffix search path under TCP/IP 
settings for the workstation. 


The underscore (_) character is part of default cluster-related object names. Because it is 
not supported by the DNS RFC, some DNS name servers cannot resolve default cluster- 
related object names. 


NetWare 6.5 uses Service Location Protocol (SLP) to advertise service information 
across TCP/IP-based networks, which provides short name resolution of TCP/IP-based 
cluster resources within the network. On NetWare 6.5, Novell Cluster Services 
propagates virtual server information into SLP by default. 


Specific setup instructions for each of these short name resolution methods will be provided in 
Chapter 3, “Setting Up a Domain and Post Office in a NetWare Cluster,” on page 39. 


2.8 Deciding How to Install and Configure the Agents ina 


Cluster 


There are several cluster-specific issues to consider as you plan to install the NetWare MTA and POA 
in your clustered GroupWise system: 


+ Section 2.8.1, “Planning Secondary IP Addresses and Cluster-Unique Port Numbers for Agents 
in the Cluster,” on page 27 


+ Section 2.8.2, “Determining Appropriate Failover Paths for the Agents,” on page 29 


+ Section 2.8.3, “Deciding Where to Install the Agent Software,” on page 29 


+ Section 2.8.4, “Deciding Whether to Run the Agents in Protected Memory,” on page 31 


+ Section 2.8.5, “Planning the NetWare Agent Installation,” on page 32 
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2.8.1 


Planning Secondary IP Addresses and Cluster-Unique Port Numbers 
for Agents in the Cluster 


The GroupWise agents listen on all IP addresses, both primary and secondary, that are bound to the 


server on their specified port numbers. This means that any time there is a possibility of two of the 


same type of agent loading on the same node, it is important that each agent use a cluster-unique port 


number, even though each agent is using a unique secondary IP address. The best way for you to 
avoid port conflicts is to plan your cluster so that each agent in the cluster runs on a cluster-unique 
port. Print out a copy of the “IP Address Worksheet” on page 35 to help you plan secondary IP 


addresses and cluster-unique port numbers for all GroupWise agents. 


The following filled-out version of the IP Address Worksheet illustrates one way this can be done: 


Domain Information 


Domain MTA 
IP Address 
Provo1 172.16.5.81 


Post Office Information 


: POA 
Post Office IP Address 
Development (same as MTA) 


Manufacturing 172.16.5.82 


Internet Agent Information 


GWIA 
Internet Agent IP Address 
GWIA Domain 172.16.5.83 
MTA 
Internet Agent (same as MTA) 
(GWIA) 


MTA MTA 

MTP Port HTTP Port 

7100 7180 

POA POA POA 

CIS Port MTP Port HTTP Port 

1677 7101 7181 

1678 7102 7182 
MTA MTA Live le GWIA 
MTP Port Remote Port HTTP Port 

Port 

7110 7677 7183 N/A 
N/A N/A N/A 9850 
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WebAccess Information 


WebAccess WebAccess MTA pla WebAccess WebAccess 
Agent IP Address MTP Port Port Agent Port HTTP Port 
WebAccess 172.16.5.84 7120 7184 N/A N/A 

Domain MTA 

WebAccess Agent (same as MTA) N/A N/A 7205 7205 
(GWINTER) (same as agent) 


This example places the Development post office on the same node and on the same GroupWise 
volume with the Provo1 domain; therefore, the Provo1 MTA and the Development POA can use the 
same secondary IP address. The Manufacturing post office is placed on a different node on a different 
GroupWise volume, so that the Manufacturing post office has a different secondary IP address. 


The example also illustrates that the MTA, the POA, and the Internet Agent use different port 
numbers for agent ports and HTTP ports. In contrast, the WebAccess Agent uses the same port 
number for the agent port and the HTTP port. 


The example uses default port numbers where possible. For example, the default MTA message 
transfer port is 7100 and the default POA client/server port is 1677. Incrementing port numbers are 
used in the example when multiple components have the same type of ports. For example, port 
numbers 1677 and 1678 are both POA client/server ports and port numbers 7180 through 7184 are all 
HTTP ports. Incrementing from the default port numbers generates unique, though related, port 
numbers. 


If you are going to set up a GroupWise name server to help GroupWise clients locate their post 
offices, make sure that the default POA port number of 1677 is used somewhere in the cluster. For 
more information, see “Simplifying Client/Server Access with a GroupWise Name Server” in “Post 
Office Agent” in the GroupWise 8 Administration Guide. 


IP ADDRESS WORKSHEET 


Fill out the “IP Address Worksheet” on page 35 to help you plan secondary IP addresses and cluster- 
unique port numbers for all GroupWise agents in the cluster. (MTA, POA, Internet Agent, WebAccess 
Agent). 


After you have filled out the IP Address Worksheet, transfer the secondary IP addresses and cluster- 
unique port numbers from the IP Address Worksheet to the System Clustering Worksheet and the 
Agent Clustering Worksheet so that they are available in the sequence in which you will need them 
as you set up GroupWise in a cluster. 


SYSTEM CLUSTERING WORKSHEET 


If you are setting up a new GroupWise system, under Item 6: Shared Volumes for GroupWise 
Administration, specify secondary IP addresses for your GroupWise administration volumes. 


Under Item 7: Shared Volume for Domain, use the domain MTA secondary IP address from the IP 
Address Worksheet as the domain volume IP address. 


If you are planning the post office on a different volume from the domain, under Item 8: Shared 
Volume for Post Office, use the post office POA secondary IP address from the IP Address 
Worksheet as the post office volume IP address. 
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2.8.2 


2.8.3 


AGENT CLUSTERING WORKSHEET 


Under Item 4: MTA Network Information, transfer the secondary IP address and cluster-unique port 
numbers for the MTA from the IP Address Worksheet to the Agent Clustering Worksheet. 


Under Item 7: POA Network Information, transfer the secondary IP address and cluster-unique port 
numbers for the POA from the IP Address Worksheet to the Agent Clustering Worksheet. 


Determining Appropriate Failover Paths for the Agents 


By default, a GroupWise volume is configured to have all nodes in the cluster in its failover path, 
organized in ascending alphanumeric order. Only one node at a time can have a particular 
GroupWise volume mounted and active. If a GroupWise volume’s preferred node fails, the volume 
fails over to the next node in the failover path. You will want to customize the failover path for each 
GroupWise volume based on the fan-out-failover principle. 


When a node fails, its volumes should not all fail over together to the same secondary node. Instead, 
the volumes should be distributed across multiple nodes in the cluster. This prevents any one node 
from shouldering the entire processing load typically carried by another node. In addition, some 
volumes should never have the potential of being mounted on the same node during a failover 
situation. For example, a post office and POA that service a large number of very active GroupWise 
client users should never fail over to a node where another very large post office and heavily loaded 
POA reside. If they did, users on both post offices would notice a decrease in responsiveness of the 
GroupWise client. 


AGENT CLUSTERING WORKSHEET 


Under Item 3: Domain Failover Path, list the nodes that you want to have in the domain volume 
failover path. The MTA might need to run on any node that the domain volume fails over to. 


If you are planning the post office on a different GroupWise volume from where the domain is located, 
under Item 6: Post Office Failover Path, list the nodes that you want to have in the post office volume 
failover path. The POA might need to run on any node that the post office volume fails over to. 


Deciding Where to Install the Agent Software 


When you install the NetWare MTA and POA in a clustering environment, you can choose between 
two different installation locations: 


Table 2-3 Agent Software Installation Locations 


Location Description 

sys:\system This is the default location provided by the Agent Installation program. Because 

on each node the agents must be installed on each node where they might need to run during 

in the cluster a failover situation, you need to do one of the following if you select this 
alternative: 


+ Run the Agent Installation program multiple times in order to install the 
agent software and to create the agent startup files on each node that is 
on a GroupWise volume failover path. 


+ Run the Agent Installation program, then copy the agent software and 
startup files to each node that is on a GroupWise volume failover path. 
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Location Description 


system directory If you create a vol: \system directory on a GroupWise volume, the agent 
on each GroupWise software and startup files fail over and back with the domains and post offices 
volume that the agents service. 


Unless you have a very small GroupWise system with all domains and post 
offices on a single GroupWise volume, you still need to install the agent 
software multiple times, once to each GroupWise volume. 


A simple way to look at the agent location alternatives would be that if you have fewer nodes on 
failover paths than you have GroupWise volumes for domains and post offices, then it would be most 
efficient to install the agent software to the nodes. Conversely, if you have fewer GroupWise volumes 
than you have nodes on failover paths, then it would be most efficient to install the agent software to 
the GroupWise volumes. However, there are issues to consider that extend beyond efficiency during 
installation. 


The following sections can help you choose which installation location would be best for your 
clustered GroupWise system: 


+ 


+ 


+ 


“Advantages of a vol:\system Directory on Each GroupWise Volume” on page 30 
“Disadvantages of a vol: \ system Directory on Each GroupWise Volume” on page 30 


“Recommendation” on page 31 


Advantages of a vol:\system Directory on Each GroupWise Volume 


Using a vol: \system directory on each GroupWise volume has several advantages: 


+ 


If you change information in the agent startup files, you only need to change it in one place, not 
on every node on any GroupWise volume failover path. 


Having the agent startup files on the same GroupWise volume as the domain or post office 
makes them easy to find. 


When you update the agent software, you only need to update it in one place for a particular 
domain or post office, not on every node on a GroupWise volume failover path. This prevents 
the potential problem of having a domain or post office fail over to a location where a different 
version of the agent software is installed. 


If you ever need to add or replace a physical server in the cluster, you only need to install 
NetWare and Novell Cluster Services to the new server, then add that node to the appropriate 
failover paths. No extra GroupWise configuration is necessary because there are no 

sys: \system dependencies for the GroupWise agents. 


If you want to back up the GroupWise software, you do not have to include the sys: \system 
directory in the backup. 


Disadvantages of a vol:\system Directory on Each GroupWise Volume 


Installing the agents on a GroupWise volume does have some disadvantages: 


+ 


+ 


GroupWise administrators who are used to the GroupWise agents being installed in 
sys: \system might be confused by not finding them there in the clustered GroupWise system. 


You must remember where you installed the GroupWise agents when you update the agent 
software. Accidently installing a GroupWise Support Pack to the default location of 

sys: \system would not have the desired results if the original agent software was installed to 
the vol: \system directory on a GroupWise volume. 
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Recommendation 


Whichever method you choose, be consistent throughout the entire cluster. Either put all the 
GroupWise agents on the GroupWise volumes with the domains and post offices they service, or put 
them all in sys: \system directories. If you put them on GroupWise volumes, make sure there are no 
agent files in sys: \system directories to confuse the issue at a later time. 


Even if you choose to install the agents to multiple sys: \system directories, you can still store the 
agent startup files on the GroupWise volumes. The significant advantage of this approach is that you 
only have one startup file to modify per agent. 


AGENT CLUSTERING WORKSHEET 


Under Item 1: Agent Installation Location, mark whether you will install the agent software to a 
vol:\system directory on a GroupWise volume or to sys: \system on each node in the cluster. If 
necessary, specify where the agent startup files will be stored. 


Under Item 2: Domain Name, transfer the domain name and location from the System Clustering 
Worksheet to the Agent Clustering Worksheet. 


Under Item 5: Post Office Name, transfer the post office name and location from the System 
Clustering Worksheet to the Agent Clustering Worksheet. 


Deciding Whether to Run the Agents in Protected Memory 


On a NetWare server, using protected memory allows you to create isolated memory spaces where 
NLM programs can run without affecting other NLM programs running on the same node. This 
contributes to the high availability of the cluster. Using protected memory has the following 
advantages: 


+ When using protected memory, the node can restart a specific memory space if any NLM 
program within that memory space abends. This allows for recovery without failing the entire 
node, which enhances both up time and database integrity. 


+ Using protected memory gives you the ability to unload a single instance of an agent, rather 
than all instances. 


¢ If you use protected memory, you can run the agents in active/active mode, rather than active/ 
passive mode. 


If you have any possibility of the same type of GroupWise agent loading multiple times on any node 
in the cluster, you must use protected memory so that you can unload agents individually. Check 
your failover paths (Agent Clustering Worksheet items 3 and 6) for failover combinations where 
multiple instances of the same type of agent might need to run on the same node. 


Protected memory does result in higher memory utilization (about 5% to 10%) and a slight 
performance penalty. Make sure your nodes have sufficient memory to handle the number of 
memory spaces that might reside on them. Keep in mind that if you load the MTA and the POA in 
different memory spaces, the agent engine (gwenn5 .n1m) will load twice on the node. Remember to 
provide memory for any GroupWise volumes that could fail over to a node, in addition to that node’s 
regular processing load. 





IMPORTANT: For optimum stability, we strongly recommend that you run the agents in protected 
memory, with one agent per memory space. 
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AGENT CLUSTERING WORKSHEET 


Under Item 8: Load Agents in Protected Memory?, mark whether or not you need to run the 
GroupWise agents in protected memory. 


If you will use protected memory, provide one or two unique protected memory space names. If you 
will create the domain and post office on the same GroupWise volume, the MTA and POA can use the 
same memory space, although this is not recommended. If you will create the domain and post office 
on different GroupWise volumes, the MTA and POA must use different memory spaces. 


2.8.5 Planning the NetWare Agent Installation 


Aside from the cluster-specific issues discussed in the preceding sections, the considerations 
involved in planning to install the GroupWise NetWare agents are the same in a clustering 
environment as for any other environment. Review “Planning the GroupWise Agents”, then print 
and fill out the “GroupWise Agent Installation Summary Sheet” in “Installing GroupWise Agents” in 
the GroupWise 8 Installation Guide for each location where you will install the NetWare MTA and/or 
POA. 


Fill out the NetWare Agent Worksheet, taking into account the following cluster-specific issues: 


GROUPWISE AGENT INSTALLATION WORKSHEET 


Under Agents and Locations, mark POA Local to Post Office and MTA Local to Domain. Ina 
clustering environment, a domain or post office and its agent must reside on the same GroupWise 
volume in order to fail over together. 


Under Installation Path, take into account your decision based on “Deciding Where to Install the Agent 
Software” on page 29. 


Under Installation Options for your agent platform, mark Yes for Configure the GroupWise Agents for 
Clustering. This will cause the Agent Installation program to customize the agent startup files for 
clustering. 


Under Domain Information and Post Office Information, refer to the Domain and Post Office 
Worksheets you filled out in Section 2.3, “Planning a New Clustered Domain,” on page 21 and 
Section 2.4, “Planning a New Clustered Post Office,” on page 22, and to the IP Address Worksheet 
you completed during “Planning Secondary IP Addresses and Cluster-Unique Port Numbers for 
Agents in the Cluster” on page 27. 


Under Launch GroupWise Agents Now, mark No. 





IMPORTANT: Do not install the NetWare agent software until you are instructed to do so in 
Chapter 3, “Setting Up a Domain and Post Office in a NetWare Cluster,” on page 39. 





Skip to Chapter 3, “Setting Up a Domain and Post Office in a NetWare Cluster,” on page 39. 


2.9 GroupWise Clustering Worksheets 


+ Section 2.9.1, “System Clustering Worksheet,” on page 33 
+ Section 2.9.2, “IP Address Worksheet,” on page 35 
+ Section 2.9.3, “Agent Clustering Worksheet,” on page 36 
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2.9.1 


System Clustering Worksheet 


Item 


1) Software Version Updates 
for Cluster: 


2) eDirectory Tree for Cluster: 


3) Cluster Name: 


Cluster IP Address: 


4) Cluster Context: 


5) Nodes in Cluster 


6) Shared Volumes for GroupWise 
Administration: 


Cluster Enabled? 
+ Yes (highly recommended) 
Cluster volume IP addresses 
+ No 


GroupWise Administration Snap-ins to 
ConsoleOne 


+ public directory 


+ Other 


GroupWise Software Distribution 
Directory 


+ \grpwise\software directory 
+ Other 


Explanation 


List any servers that need to be updated so that all nodes in 
the cluster are running the same version of NetWare. 


For more information, see Section 2.1, “Meeting Software 
Version Requirements,” on page 20. 


Record the eDirectory tree where you created the new Novell 
Cluster object when you installed Novell Cluster Services. 


For more information, see Section 2.2, “Installing Novell 
Cluster Services,” on page 20 


Record the name of the new NetWare Cluster object that you 
created for your GroupWise system. Also record the virtual IP 
address of the cluster that will remain constant regardless of 

which node is currently active. 


For more information, see Section 2.2, “Installing Novell 
Cluster Services,” on page 20. 


Record the full context where you created the new NetWare 
Cluster object. 


For more information, see Section 2.2, “Installing Novell 
Cluster Services,” on page 20. 


List the nodes that are part of the cluster that you set up for 
your GroupWise system. 


For more information, see Section 2.2, “Installing Novell 
Cluster Services,” on page 20. 


Specify the names (c/uster_volume) of the shared volumes 
where the GroupWise administration snap-ins to ConsoleOne 
and the GroupWise software distribution directory will reside. 


For cluster-enabling, specify the IP addresses of the virtual 
servers (volume_SERVER.cluster) to which the cluster- 
enabled volumes are tied. 


For more information, see Section 2.6, “Deciding Whether to 
Cluster-Enable the Shared Volumes Used by GroupWise,” on 
page 23. 
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Item 
7) Shared Volume for Domain: 
Cluster Enabled? 


+ Yes (highly recommended) 


Cluster volume IP address 


+ No 


Post Office on Same Volume as 
Domain? 


+ Yes 

+ No 
8) Shared Volume for Post Office: 
Cluster Enabled? 

+ Yes (highly recommended) 


Cluster volume IP address 


+ No 


9) IP Address Resolution Methods: 


+ eDirectory 

+ hosts file 

¢ DNS 

+ SLP (highly recommended) 


10) Domain Name: 


Domain Database Location: 


11) Post Office Name: 


Post Office Database Location: 


GroupWise 8 Interoperability Guide 


Explanation 


Specify the name (cluster_volume) of the shared volume 
where the GroupWise domain will reside. 


For cluster-enabling, specify the IP address of the virtual 
server (volume_SERVER.cluster) to which the cluster-enabled 
volume is tied. 


For more information, see Section 2.4, “Planning a New 
Clustered Post Office,” on page 22 and Section 2.6, “Deciding 
Whether to Cluster-Enable the Shared Volumes Used by 
GroupWise,” on page 23. 


Specify the name (cluster_volume) of the shared volume 
where the GroupWise post office will reside. 


For cluster-enabling, specify the IP address of the virtual 
server (volume_SERVER.cluster) to which the cluster-enabled 
volume is tied. 


For more information, see Section 2.4, “Planning a New 
Clustered Post Office,” on page 22 and Section 2.6, “Deciding 
Whether to Cluster-Enable the Shared Volumes Used by 
GroupWise,” on page 23. 


Mark the short name address resolution methods you want to 
implement to ensure that the UNC paths stored in ConsoleOne 
can be successfully resolved into physical network addresses. 


For more information, see Section 2.7, “Ensuring Successful 
Name Resolution for GroupWise Volumes,” on page 25 


Specify a unique name for the domain. Specify the directory on 
the GroupWise volume where you want to create the new 
domain. 


For more information, see Section 2.3, “Planning a New 
Clustered Domain,” on page 21. 


Specify a unique name for the post office. Specify the directory 
on the GroupWise volume where you want to create the post 
office. 


For more information, see Section 2.4, “Planning a New 
Clustered Post Office,” on page 22. 


2.9.2 


Item 


12) Document Storage Area Location: 


+ At the post office 
+ Outside the post office 


+ Separate post office 
Document Storage Area Access 


+ POA /user startup switch setting 


+ POA /password startup switch 
setting 


IP Address Worksheet 


Explanation 


If you need a library for a clustered post office, mark where you 
want to create its document storage area and provide a 
directory if necessary. 


For more information, see Section 2.5, “Planning a New 
Library for a Clustered Post Office,” on page 23. 


+ “Domain Information” on page 35 


¢ “Post Office Information” on page 35 


+ “Internet Agent Information” on page 35 


+ “WebAccess Information” on page 36 


Domain Information 


Domain MTA MTA MTA 
IP Address MTP Port HTTP Port 
Post Office Information 
Post Office POA POA POA POA 
IP Address CIS Port MTP Port HTTP Port 
Internet Agent Information 
Internet Agent GWIA MTA ive Remote MTA GWIA 
g IP Address MTP Port Port HTTP Port HTTP Port 
GWIA Domain N/A 
MTA 
Internet Agent (same) N/A N/A N/A 
(GWIA) 
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2.9.3 


WebAccess Information 


MTA 
MTP Port 


WebAccess 
IP Address 


WebAccess 
Agent 


WebAccess 
Domain MTA 


WebAccess 
Agent 
(GWINTER) 


(same) N/A 


Agent Clustering Worksheet 


Item 
1) agent installation location: 


+ vol:\system on the GroupWise 
volume 


+ sys:\system on each node 


Consolidate multiple startup files on 
GroupWise volume? 


2) Domain Name: 
Domain Location: 


3) Domain Failover Path: 


4) MTA Network Information: 


+ MTA IP address 
+ MTA message transfer port 


+ MTA HTTP port 
5) Post Office Name: 
Post Office Location: 


6) Post Office Failover Path: 
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MTA WebAccess WebAccess 
HTTP Port Agent Port HTTP Port 
N/A N/A 
N/A 
Explanation 


Mark the location where you will install the agent 
software. 


If necessary, specify the location where you will 
consolidate multiple agent startup files on a GroupWise 
volume. 


For more information, see “Deciding Where to Install the 
Agent Software” on page 29. 


Transfer this information from the System Clustering 
Worksheet (item 10). 


List other nodes in the cluster where the GroupWise 
domain and its MTA could fail over. 


For more information, see “Determining Appropriate 
Failover Paths for the Agents” on page 29. 


Gather the MTA network address information from the 
“IP Address Worksheet” on page 35. 


For more information, see “Planning Secondary IP 
Addresses and Cluster-Unique Port Numbers for Agents 
in the Cluster” on page 27. 


Transfer this information from the System Clustering 
Worksheet (item 11). 
List other nodes in the cluster where the GroupWise post 


office and its POA could fail over. 


For more information, see “Determining Appropriate 
Failover Paths for the Agents” on page 29. 


Item 
7) POA Network Information: 


+ POA IP address 
+ POA client/server port 
+ POA message transfer port 


+ POA HTTP port 
8) Load Agents in Protected Memory? 


+ No 


+ Yes 


MTA protected address space 

POA protected address space 

POA /user startup switch setting 
POA /password startup switch setting 


Explanation 


Gather the POA network address information from the 
“IP Address Worksheet” on page 35. 


For more information, see “Planning Secondary IP 
Addresses and Cluster-Unique Port Numbers for Agents 
in the Cluster” on page 27. 


Mark whether you need to run the agents in protected 
memory. If so, specify a unique address space for each 
agent. For the POA, specify a user name and password 
if required by your version of NetWare. 


For more information, see “Deciding Whether to Run the 
Agents in Protected Memory” on page 31. 
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3.1 


3.1.1 


3.1.2 


Setting Up a Domain and Post Office in a 
NetWare Cluster 


You should have already reviewed “Planning GroupWise in a NetWare Cluster” on page 19 and 
filled out the “System Clustering Worksheet” on page 33, the “IP Address Worksheet” on page 35, 
and the “Agent Clustering Worksheet” on page 36. You are now ready to complete the following 
tasks to set up GroupWise in a clustering environment: 


+ 


+ 


+ 


Section 3.1, “Preparing the Cluster for GroupWise,” on page 39 

Section 3.2, “Setting Up a New GroupWise System in a Cluster,” on page 42 

Section 3.3, “Creating a New Secondary Domain in a Cluster,” on page 43 

Section 3.4, “Creating a New Post Office in a Cluster,” on page 44 

Section 3.5, “Installing and Configuring the MTA and the POA in a Cluster,” on page 46 
Section 3.6, “Testing Your Clustered GroupWise System,” on page 54 

Section 3.7, “Managing Your Clustered GroupWise System,” on page 55 

Section 3.8, “What's Next,” on page 59 

Section 3.9, “Clustering Quick Checklists,” on page 59 


Preparing the Cluster for GroupWise 


After you have installed Novell Cluster Services, as described in Novell Cluster Services Overview and 
Installation, complete the following tasks to prepare the cluster for your GroupWise system: 


+ 


+ 


+ 


Section 3.1.1, “Ensuring Required Software Versions,” on page 39 
Section 3.1.2, “Cluster-Enabling Shared Volumes for Use with GroupWise,” on page 39 
Section 3.1.3, “Configuring Short Name Resolution,” on page 40 


Ensuring Required Software Versions 


Double-check each node in the cluster to make sure it meets the requirements described in 
Section 2.1, “Meeting Software Version Requirements,” on page 20. 


Cluster-Enabling Shared Volumes for Use with GroupWise 


To cluster-enable a shared volume for use with GroupWise: 


1 Select a System Clustering Worksheet item (6, 7, or 8) where you marked Yes under Cluster 


Enabled?. 
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3.1.3 


2 Complete the steps in the cluster-enabling section of the cluster documentation for your version 
of NetWare, as listed in Chapter 1, “Introduction to GroupWise 8 and Novell Cluster Services on 
NetWare,” on page 17. 


The System Clustering Worksheet provides the volume to cluster-enable for use the GroupWise, 
the cluster-enabled volume IP address, and the failover path for the GroupWise volume. 


For a review of the new Novell eDirectory objects that are created when you cluster-enable a 
shared volume, see Section 2.6, “Deciding Whether to Cluster-Enable the Shared Volumes Used 
by GroupWise,” on page 23. 


If you have installed the latest version of ConsoleOne and the Novell Cluster Services snap-in, 
you can rename the cluster-related objects in case your DNS name server cannot resolve object 
names that include the underscore (_) character. 


3 Repeat Step 1 and Step 2 above for the other shared volumes on your System Clustering 
Worksheet that need to be cluster-enabled. 


4 Continue with Configuring Short Name Resolution. 


Configuring Short Name Resolution 


To ensure that GroupWise volumes are always locatable, configure the short name resolution 
methods that you want to rely on for GroupWise (System Clustering Worksheet item 9): 

¢ “eDirectory” on page 40 

¢ “Hosts Files” on page 41 

¢ “DNS” on page 41 

+ “SLP” on page 42 
After configuring your selected short name resolution methods, continue with the task you need to 
perform: 

¢ “eDirectory” on page 40 

¢ “Hosts Files” on page 41 

+ “DNS” on page 41 

+ “SLP” on page 42 


eDirectory 


Most commonly, you will use eDirectory to resolve the UNC path of a volume into its network 
address. For example, on the workstation where you run ConsoleOne, you need to map a drive to the 
location of a domain directory so that ConsoleOne can access the domain database. You could use a 
map command as shown in the example below: 


Syntax: 

map drive: = .cluster_volume.context 
Example: 

map m: = .GWCLUSTER_GWVOL1.GWServers 


When specifying the map commands, use System Clustering Worksheet item 3 for cluster. Use System 
Clustering Worksheet item 7 or 8 for each volume where a domain or post office resides. Use System 
Clustering Worksheet item 4 for context. 
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Hosts Files 


Because each GroupWise volume where you plan to create a domain or post office has been 
associated with a virtual server, you should add lines for the new virtual servers to one or more of the 
following files as needed: 


+ NetWare: 
sys:\etc\hosts 
(on all nodes in the cluster; recommended) 


+ Windows XP/Vista: 
\winnt\system32\drivers\etc\hosts 
(on the administrator’s workstation only; optional) 


The lines you add to a hosts file could look similar to the following example: 
Syntax: 
IP address cluster_volume_SERVER.context cluster_volume_SERVER 


Remember that cluster_volume_SERVER represents the name of the virtual server created when you 
cluster-enabled the volume. 


Example: 


172.16.5.81 gwcluster_gwvoll SERVER.gwcluster.com 
gweluster_gwvoll SERVER 


When specifying the lines in the hosts files, use System Clustering Worksheet item 7 or 8 for each 
IP_address and volume where a domain or post office resides. Use System Clustering Worksheet item 3 
for cluster. Use System Clustering Worksheet item 4 for context. 


DNS 


Because each GroupWise volume where you plan to create a domain or post office has been 
associated with a virtual server, you should add all your new virtual servers to DNS. Then you could 
use a map command as shown in the example below (all on one line, of course): 


Syntax: 
map drive: = \\volume_SERVER.cluster.com\volume 


Remember that volume_SERVER represents the name of the Volume Resource object created when 
you cluster-enabled the volume. A cluster-enabled volume can function like a server, as these 
commands illustrate. 


Example: 
map m: = \\gwvoll_ SERVER.gwcluster.com\gwvoll 
Or, if the ConsoleOne workstation is in the same DNS domain as the GroupWise volume: 
Syntax: 
map drive: = \\volume_SERVER\volume 
Example 


map m: = \\gwvoll_SERVER\gwvoll 
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When specifying the map commands you will need, use System Clustering Worksheet item 7 or 8 for 
each volume where a domain or post office resides. Use System Clustering Worksheet item 3 for 
cluster. 


SLP 


On NetWare 6.5, Novell Cluster Services automatically propagates virtual server information into 
SLP and provides the most reliable name resolution. 


Setting Up a New GroupWise System in a Cluster 


The GroupWise Installation Advisor walks you through setting up the primary domain and an initial 
post office in the primary domain. You might be creating your primary domain and initial post office 
on the same GroupWise volume or on two different volumes. After you have created the primary 
domain and initial post office and installed the GroupWise agents, you can create additional 
secondary domains and post offices as needed. 


To set up the primary domain and initial post office for a new GroupWise system in a clustering 
environment: 


1 If necessary, map a drive to each GroupWise administration volume (System Clustering 
Worksheet item 6). 


2 Map a drive to the GroupWise volume for the domain (System Clustering Worksheet item 7) 
and, if needed, to the GroupWise volume for the post office (System Clustering Worksheet item 
8), where the primary domain and the initial post office for your new GroupWise system will be 
created. 


The GroupWise volume name will be cluster_volume. For assistance with mapping a drive toa 
cluster-enabled volume, see “Configuring Short Name Resolution” on page 40. 


3 Manually create the domain directory (System Clustering Worksheet item 10) and the post office 
directory (System Clustering Worksheet item 12). 


This step is not required, but in a clustered environment, the following step is easier if the 
domain directory already exists. 


4 Run the GroupWise Installation Advisor to set up your initial GroupWise system, following the 
steps provided in “NetWare and Windows: Setting Up a Basic GroupWise System” in “Installing 
a Basic GroupWise System” in the GroupWise 8 Installation Guide. Keep in mind the following 
cluster-specific details: 


+ When you specify the ConsoleOne directory and the software distribution directory, be sure 
to browse to each location through the GroupWise volume accessed in Step 1 above. 


+ When you specify the domain directory and post office directory, be sure to browse through 
the GroupWise volume accessed in Step 2 to select the directory created in Step 3 above. 


¢ For the post office link type, select TCP/IP Link. 


¢ When providing the MTA and POA network address information, use the Agent Clustering 
Worksheet that you filled out in Section 2.8, “Deciding How to Install and Configure the 
Agents in a Cluster,” on page 26. The information you provide is used to configure the MTA 
and POA objects in the domain and post office even though you have not yet installed the 
agent software. 


+ Do not create users in the post office at this time. 


+ In the Summary dialog box, the domain directory and post office directory that you 
browsed to should display as UNC paths using the virtual server name with the 
GroupWise volume. 
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GroupWise System Setup [x] 








Summary 
System name: Corporate 
Tree: CORP_TREE 
Domain name: Provo1 
Dornain context: GroupWise.Provo 


Domain directory: \GW-CLUSTER_GWVOL_SERVER\ 
Domain time zone: (GMT-07:00) Mountain Time (US & C 
Domain language: English- US 

Post office name: Development 

Postoffice context:  GroupWise.Provo 

Post office directory: \GWW-CLUSTER_GWVOL_SERVER\ 
Post office time zone: (GMT-07:00) Mountain Time (US &C ~ 




















Ifthe above information is correct, click Next to create your 
Groupwise system. To correct any information, click Back until 
you reach the appropriate page. 


= Back | 





k Cancel | Kimen | Help | 





5 When you have finished creating the primary domain and the initial post office, continue with 
installing the GroupWise Agents, starting with Step 4 on page 46 in Section 3.5, “Installing and 
Configuring the MTA and the POA in a Cluster,” on page 46. 


Creating a New Secondary Domain in a Cluster 


After you have set up the primary domain and initial post office, as described in Section 3.2, “Setting 
Up a New GroupWise System in a Cluster,” on page 42, you can create additional secondary domains 
as needed. 


To create a new secondary domain in a clustering environment: 
1 Map a drive to the GroupWise volume for the domain (System Clustering Worksheet item 7) 
where the new secondary domain will be created. 


The GroupWise volume name will be cluster_volume. For assistance with mapping a drive toa 
cluster-enabled volume, see “Configuring Short Name Resolution” on page 40. 


2 Manually create the domain directory (System Clustering Worksheet item 10). 


This step is not required, but in a clustered environment, Step 5 is easier if the domain directory 
already exists. 


3 If you selected vol: \system on GroupWise volume as the agent installation location (under 
Agent Clustering Worksheet item 1), create the vol: \system directory on the GroupWise 
volume accessed in Step 1. 


or 
If you selected sys: \system on each node, decide which node you will install the agents to first. 


4 InConsoleOne, connect to the primary domain in your GroupWise system, as described in 
“Connecting to a Domain” in “Domains” in the GroupWise 8 Administration Guide. 


5 Create the new domain, following the steps provided in “Creating the New Domain” in 
“Domains” in the GroupWise 8 Administration Guide. Keep in mind the following cluster-specific 
details: 


¢ Use the Domain Worksheet you filled out in Section 2.3, “Planning a New Clustered 
Domain,” on page 21 to fill in the fields in the Create GroupWise Domain dialog box. 


+ In the Domain Database Location field, be sure to browse through the drive you mapped in 
Step 1 to the domain directory you created in Step 2 above. 
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¢ In the Link to Domain field, link the new domain to the primary domain of your GroupWise 
system. 


+ The Configure Link option is selected by default. Select TCP/IP Link to the Other Domain. 
Refer to the Agent Clustering Worksheet that you filled out in “Planning Secondary IP 
Addresses and Cluster-Unique Port Numbers for Agents in the Cluster” on page 27 for the 
secondary IP address and cluster-unique port numbers that you need to specify in order to 
configure the link. 


Use the Link Configuration tool to change the links from the new domain to all other domains in 
the cluster to direct TCP/IP links, following the steps provided in “Changing the Link Protocol 
between Domains to TCP/IP” in “Message Transfer Agent” in the GroupWise 8 Administration 
Guide. 


Although a complete mesh link configuration is the most efficient, it might not be feasible in all 
situations. Set up as many direct TCP/IP links as possible for best MTA performance in the 
cluster. 


Make sure you are still connected to the primary domain. 


Rebuild the domain database for the new domain, following the steps provided in “Rebuilding 
Domain or Post Office Databases” in “Databases” in the GroupWise 8 Administration Guide. Be 
sure to browse to the database location (under System Clustering Worksheet item 10) through 
the virtual server that was created when you cluster-enabled the GroupWise volume. 


The database rebuild is necessary in order to transfer the MTA configuration information and 
the domain link information into the secondary domain database, because the MTA for the new 
domain is not yet running. 


Continue with Creating a New Post Office in a Cluster. 


Creating a New Post Office in a Cluster 


You can create a new post office on the same GroupWise volume where its domain resides or on a 
separate GroupWise volume. If the post office and its domain are on the same GroupWise volume, 
they fail over together. If they are on separate GroupWise volumes, they fail over separately. 


To create a new post office in a clustering environment: 


1 If you marked Yes for Post Office on Same Volume as Domain? (under System Clustering 


Worksheet item 7), map a drive to the GroupWise volume for the domain (System Clustering 
Worksheet item 7). 


or 
Map a drive to the GroupWise volume for the post office (System Clustering Worksheet item 8). 


The GroupWise volume name will be cluster_volume. For assistance with mapping a drive toa 
cluster-enabled volume, see “Configuring Short Name Resolution” on page 40. 


Manually create the post office directory (System Clustering Worksheet item 12). 


This step is not required, but in a clustered environment, Step 4 is easier if the post office 
directory already exists. 


In ConsoleOne, connect to the GroupWise domain where you want to create the new post office, 
as described in “Connecting to a Domain” in “Domains” in the GroupWise 8 Administration 
Guide. 
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4 Create the new post office, following the steps provided in “Creating the New Post Office” in 
“Post Offices” in the GroupWise 8 Administration Guide. Keep in mind the following cluster- 
specific details: 


¢ Use the Post Office Worksheet you filled out in Section 2.4, “Planning a New Clustered Post 
Office,” on page 22 to fill in the fields in the Create GroupWise Post Office dialog box. 

+ In the Post Office Database Location field, be sure to browse through the drive you mapped in 
Step 1 to the post office directory you created in Step 2 above. 


+ If you want to create a library at the post office (System Clustering Worksheet item 14), 
select Create Library. 


This option creates the document storage area for the library under the post office directory 
and is not recommended for large libraries. 


¢ The Configure Link option is selected by default. Select TCP/IP Link from Domain to New Post 
Office. Refer to the Agent Clustering Worksheet that you filled in during “Planning 
Secondary IP Addresses and Cluster-Unique Port Numbers for Agents in the Cluster” on 
page 27 for the secondary IP address and cluster-unique port numbers that you need to 
specify in order to configure the link. 


5 Right-click the new Post Office object, then click Properties. 
6 Click GroupWise > Post Office Settings; in the Access Mode field, select Client/Server Only. 
7 Right-click the new POA object, then click Properties. 


On the POA Agent Settings and Scheduled Events pages, you might want to specify unique 
times for the following POA activities to prevent multiple POAs from performing the same 
activities on the same node at the same time during a failover situation: 


¢ Start User Upkeep 

+ Generate Address Book for Remote 
¢ Enable QuickFinder Indexing 

¢ Mailbox/Library Maintenance Event 


For more information about these repetitive POA activities, see “Performing Nightly User 
Upkeep”, “Regulating Indexing”, and “Scheduling Database Maintenance” in “Post Office 
Agent” in the GroupWise 8 Administration Guide. 


8 Make sure you are still connected to the domain that owns the new post office. 


9 Rebuild the post office database for the new post office, following the steps provided in 
“Rebuilding Domain or Post Office Databases” in “Databases” in the GroupWise 8 Administration 
Guide. Be sure to browse to the database location (under System Clustering Worksheet item 11) 
through the virtual server that was created when you cluster-enabled the GroupWise volume. 


The database rebuild is necessary in order to transfer the POA configuration information and 
the post office link information into the post office database, because the POA for the new post 
office is not yet running. 


10 If you want to create a library with its document storage area outside the post office directory, 
(System Clustering Worksheet item 14), follow the steps in “Setting Up a Basic Library” or 
“Setting Up a Full-Service Library” in “Libraries and Documents” in the GroupWise 8 
Administration Guide, after you have completely finished setting up the clustered post office. 


11 Continue with Installing and Configuring the MTA and the POA in a Cluster. 
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3.5.1 


Installing and Configuring the MTA and the POA ina 
Cluster 


After you have created a new domain and/or post office, you are ready to install and configure the 
GroupWise agents. Complete all the tasks below if you are setting up a new GroupWise system or if 
you have created a new GroupWise volume where you want to install the agent software: 
+ Section 3.5.1, “Installing the Agent Software in a Cluster,” on page 46 
+ Section 3.5.2, “Editing Clustered Agent Startup Files,” on page 47 
è Section 3.5.3, “Configuring the GroupWise Volume Resource to Load and Unload the Agents,” 
on page 48 
è Section 3.5.4, “Setting Up New Instances of the Agents without Installing the Agent Software,” 
on page 52 
Under some circumstances, the agent software has already been installed and you simply need to 
create a new startup file specific to the new domain or post office. For example: 
¢ You have created anew domain and/or post office on a GroupWise volume where the agent 
software is already installed in the vol: \system directory of the GroupWise volume. 
+ In your GroupWise system, the agent software is already installed to multiple sys: \system 
directories. 


In these circumstances, follow the instructions in “Setting Up New Instances of the Agents without 
Installing the Agent Software” on page 52 instead of completing the tasks above. 


Installing the Agent Software in a Cluster 


To install the MTA and the POA: 
1 Map a drive to the GroupWise volume for the domain (Agent Clustering Worksheet item 2) or 
the post office (Agent Clustering Worksheet item 5). 


The GroupWise volume name will be cluster_volume. For assistance with mapping a drive toa 
cluster-enabled volume, see “Configuring Short Name Resolution” on page 40. 


2 If you selected vol: \system on GroupWise volume as the agent installation location (under 
Agent Clustering Worksheet item 1), create the vol: \system directory on the GroupWise 
volume accessed in Step 1. 


or 
If you selected sys: \system on each node, decide which node you will install the agents to first. 


3 Start the Agent Installation program, following the steps provided in “Installing the NetWare 
Agent Software” in “Installing GroupWise Agents” in the GroupWise 8 Installation Guide. 


4 Install the NetWare agents, keeping in mind the following cluster-specific details: 


+ Use the NetWare Agent Clustering Worksheet that you filled out in “Planning the NetWare 
Agent Installation” on page 32 to fill in the fields during the agent installation process. 


+ In the Installation Path dialog box, be sure to browse through the drive you mapped in 
Step 1 to the location you chose in Step 2 above. Also select Configure GroupWise Agents for 
Clustering. 
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¢ In the Domains / Post Offices dialog box, click Add for each domain and post office that the 
agents will service. In the Path to Database field, be sure to browse through the drive you 
mapped in Step 1 above to the domain directory or the post office directory. In the HTTP 
Port field, specify the cluster-unique HTTP port planned for each agent (under Agent 
Clustering Worksheet items 4 and 7). 


¢ In the Installation Complete dialog box, do not select Launch GroupWise Agents Now. You 
will configure the agents to launch in protected mode later. 


5 If you need to install the agents to sys: \system on multiple nodes in the cluster: 
5a Repeat Step 4, mapping new drives as needed. 


5b If you marked Yes for Consolidate Multiple Startup Files on GroupWise Volume? (under 
Agent Clustering Worksheet item 1), copy one complete set of agent startup files and the 
grpwise.ncf file to the planned location, then delete all agent startup files, as well as the 
grpwise.ncf file, from the sys: \system directories to avoid future confusion. 


The grpwise.ncf file includes a load command for each instance of each agent. You will 
use this information later when you create the load and unload scripts for the volume 
resources. 


6 Continue with Editing Clustered Agent Startup Files. 


Editing Clustered Agent Startup Files 


By default, the Agent Installation program creates agent startup files in the agent installation 
directory. Each MTA startup file is named after the domain it services, with a .mta extension. Each 
POA startup file is named after the post office it services, with a .poa extension. 


Because you selected Configure GroupWise Agents for Clustering during installation, the Agent 
Installation program set the MTA /home startup switch and the POA /home startup switch using the 
format: 


volume: \directory 
so that the startup files are valid no matter which node the agents are currently running on. 


The Agent Installation program also adds a /cluster startup switch to POA startup files to ensure that 
GroupWise clients detect the clustering environment and try more persistently to reconnect in a 
failover, failback, or migration situation. 


One additional manual modification of POA startup files is required for robust functionality in a 
clustering environment. Uncomment the /ip startup switch and provide the secondary IP address of 
the GroupWise volume where the post office is located (Agent Clustering Worksheet item 7). This 
information is available to the POA in its eDirectory object properties. However, in some failover 
situations, reconnection to the MTA is improved when the information is immediately available to 
the POA in its startup file. 


If you are running the POA in protected memory and your version of NetWare requires it, add the / 
user and /password startup switches (under Agent Clustering Worksheet item 8) in order to provide 
a user name and password that the POA can use to access its post office volume. 


If the POA needs to access a remote document storage area, add the /user and /password startup 
switches (under System Clustering Worksheet item 12) in order to provide a user name and 
password that the POA can use to access the volume where the document storage area resides. As an 
alternative to startup switches, you can assign the POA object all rights except Supervisor and Access 
control, as long as the remote document storage area is located in the same tree with the post office. 


If you have connection problems between the MTA and the POA, you can use the /user and / 
password startup switches in the MTA startup file as well. 
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3.9.3 


Configuring the GroupWise Volume Resource to Load and Unload the 
Agents 


The properties of the Volume Resource object define how the GroupWise volume functions within 
the cluster, how NLM programs are loaded and unloaded, and how failover and failback situations 
are handled. At this point, you might have one volume resource with a domain and post office on it, 
or you might have two volume resources, one for the domain and one for the post office. Complete 
the following tasks for each volume resource: 

+ “Modifying the Volume Resource Load Script for the Agents” on page 48 

e “Modifying the Volume Resource Unload Script for the Agents” on page 49 


¢ “Setting the Failover Path and Policies for the Agents” on page 50 


Modifying the Volume Resource Load Script for the Agents 


The volume resource load script executes whenever the GroupWise volume comes online. 
To set up the load script: 


1 In ConsoleOne, browse to and select the Cluster object. 
If necessary, click View > Console View to display its contents. 


2 Right-click the Volume Resource object (volume_SERVER), then click Properties > Load to display 
the default volume resource load script for the GroupWise volume. 


3 Make the following changes to the default load script: 


+ Remove the trustmig command. It is not necessary to migrate trustees for a GroupWise 
volume. Removing this line helps the load script to execute faster. 


+ If you selected vol:\system on GroupWise volume as the agent installation location 
(Agent Clustering Worksheet item 1), add a search add command to add the new 
vol:\system directory to the server search path. 


search add volume:\system 


+ If you selected sys: \system on each node as the installation location (Agent Clustering 
Worksheet item 1) but you are storing the agent startup files on the GroupWise volume, add 
that location to the server search path. 


¢ If you marked No under Load Agents in Protected Memory? (Agent Clustering Worksheet 
item 8), add the following abend recovery options: 


set auto restart after abend = 2 

set auto restart after abend delay time = 0 
set auto restart down timeout = 60 

set developer option = off 


These settings provide the best possible handling of GroupWise databases in the event that 
an abend should occur within the cluster when the agents are not running in protected 
memory. 


+ Transfer the agent load commands from the grpwise.ncf file into the load script. Use 
Ctrl+C to copy and Ctrl+V to paste text into the load script page. Then delete or rename the 
grpwise.ncf file to avoid future confusion. 


load volume:\system\agent.nlm @startup file 
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¢ If you marked Yes under Load Agents in Protected Memory? (Agent Clustering Worksheet 
item 8), add the address space parameter to the agent load commands to specify the 
protected address space for each agent. Add a protection restart command for each 
address space name. 


load address space=addr_space_name 
volume: \system\agent.nlm @startup_ file 
protection restart name 


The result would look similar to the following example: 


Properties of GWVOL_SERVER |x} 
IP Address | Load Unload | Policies | Nodes | NDS Rights ~ | Other | Rights to Files and Fold 


| Cluster Resource Load Script 


Script 





nss /activate=GVWVOL a 
mount GWWVOL VOLID=254 

cyshind add GW-CLUSTER_GWWOL_SERVER 123.45.67.18 # NetWare 5.1 only 

NUDP ADD GW-CLUSTER_GWWVOL_SERYER 123.45.67.18 

add secondary ipaddress 123.45.67.18 

search add gwvolisystem 


SET AUTO RESTART AFTER ABEND = 2 

SET AUTO RESTART AFTER ABEND DELAY TIME = 0 
SET AUTO RESTART DOWN TIMEOUT = 60 

SET DEVELOPER OPTION = OFF 


LOAD address space=devpoa GWVOLASYSTEMGWPOA @DEVELOPM.POA 
protection restart devpoa 

LOAD address space=provolmta GAVOLASYSTEMGWMTA @PROVO1.MTA 
protection restart provotmta 


i| » 
Timeout (secs) 600 











Page Options... | OK | Cancel | spay] Help | 





NOTE: The set commands are needed in the load script only when the agents are not running in 
protected memory. The address space parameters are needed in the 1oad commands only when 
the agents are running in protected memory. 





For another example of a load script, see TID 7006193: Running the GroupWise Agents in a Non- 
Protected Address Space on a NetWare Cluster in the Novell Knowledgebase (http:// 
www.novell.com/support). 


4 Click Apply to save the load script. 


5 If necessary, click OK to confirm that you must offline and then online the volume resource in 
order for the changes to take effect. 


6 Continue with Modifying the Volume Resource Unload Script for the Agents. 


Modifying the Volume Resource Unload Script for the Agents 


The volume resource unload script executes whenever the GroupWise volume goes offline. Programs 
should be unloaded in the reverse order of how they were loaded. This ensures that supporting 
programs are not unloaded before programs that rely on them in order to function properly. 


To set up the unload script: 


1 In ConsoleOne, in the properties pages for the Volume Resource object (volume_SERVER), click 
Unload to display the default volume resource unload script. 


Setting Up a Domain and Post Office in a NetWare Cluster 49 


50 


2 Make the following changes to the default unload script: 


¢ If you marked Yes under Load Agents in Protected Memory? (Agent Clustering Worksheet 
item 8), add an unload address space command for each address space. Add an unload 
kill address space command to ensure that the address space is completely cleaned up. 


unload address space=addr_space_name 
unload kill address space=addr_space_name 


¢ If you marked No under Load Agents in Protected Memory? (Agent Clustering Worksheet 
item 8), create an unload command parallel to each load command that you placed in the 
load script. 


unload agent.nlm 


+ Remove the trustmig command just like you did in the load script. 


The result would look similar to the following example: 


Properties of GWVOL_SERVER |x} 


Doria Mca herr bend separa chy 


Script 





unload address space = devpoa a 
unload address space = provoimta 


del secondary ipaddress 123.45.67.18 

NUDP DEL GY-CLUSTER_GWYVOL_SERVER 123.45.67.18 

cvshind del GvWW-CLUSTER_GWVOL_SERVER 123.45.67.18 # NetWare 5.1 only 
dismount GWVOL force 

nss forcedeactivate=GVWVOL 





Kil » 
Timeout (secs) |600 





Page Options... | OK | Cancel [aen ] Help | 





3 Click Apply to save the unload script. 


4 If necessary, click OK to confirm that you must offline and then online the volume resource in 
order for the changes to take effect. 


5 Continue with Setting the Failover Path and Policies for the Agents. 
Setting the Failover Path and Policies for the Agents 


To modify the failover path and policies for a GroupWise volume resource: 


1 In ConsoleOne, in the properties pages for the Volume Resource object (volume_SERVER), click 
Nodes to display the default failover path for the GroupWise volume resource. 
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Properties of GWYOL_SERVER 


IP Adress | Load | Unload | Policies | 


GW-CLUSTER1 


GW-CLUSTER3 
GW-CLUSTER4 











Arrange the nodes in the cluster into the desired failover path for the domain or post office 
volume (under Agent Clustering Worksheet items 3 or 6). 


Click Apply to save the failover path. 
Click Policies to display the default start, failover, and failback policies. 





Properties of GWVOL_SERVER 








The default policy settings are often appropriate. By default, a volume resource: 
¢ Fails over automatically if the node it is running on fails 
¢ Starts automatically on the next node in its failover path 


+ Continues running at its failover location, even after its most preferred node is again 
available 


If you are considering changing these defaults, see the section about failover and failback modes 
in the cluster documentation for your version of NetWare, as listed in Chapter 1, “Introduction 
to GroupWise 8 and Novell Cluster Services on NetWare,” on page 17. 


5 Click OK when you are finished editing the GroupWise volume resource properties. 


6 Skip to Section 3.6, “Testing Your Clustered GroupWise System,” on page 54. 
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3.5.4 Setting Up New Instances of the Agents without Installing the Agent 
Software 


There are two steps to setting up new instances of the agents without installing the agent software: 


+ “Creating New Startup Files” on page 52 
e “Modifying Existing Load and Unload Scripts” on page 52 


Creating New Startup Files 


Each MTA startup file is named after the domain it services, with a .mta extension. Each POA startup 
file is named after the post office it services, with a . poa extension. If the existing agent software is 
located in the vol: \system directory of a GroupWise volume, the startup files are there as well. If the 
existing agent software is located in multiple sys: \system directories, the startup files might be 
located there as well, or they might be in a directory on a GroupWise volume. 


To create a new startup file without installing the agent software: 
1 Make a copy of an existing startup file and name it after the domain or post office that will be 
serviced by the agent. 


2 Edit the setting of the /home startup switch to point to the location of the new domain directory 
or post office directory. Be careful to maintain the syntax of the original line. 


3 Scroll down through the startup file looking for other active (not commented out) startup 
switches, then modify them as needed for the new agent. 


For example, you might find that the /httpport switch is active and needs to be changed to a 
cluster-unique port number for the new agent. 


4 Save the new startup file. 


5 Continue with Modifying Existing Load and Unload Scripts. 


Modifying Existing Load and Unload Scripts 


The agent startup file names are part of the load commands found in GroupWise volume resource 
load scrips. 


If you created the new domain and/or post office on a new GroupWise volume, skip back to 
“Configuring the GroupWise Volume Resource to Load and Unload the Agents” on page 48 for 
instructions to create new load and unload scripts. 


If you created the new domain and/or post office on an existing GroupWise volume, most of the 
configuration of the volume resource has already been done. You just need to add new load and 
unload commands to the existing scripts. Continue with the steps below: 


To modify existing load and unload scripts: 


1 In ConsoleOne, browse to and select the Cluster object. 
If necessary, click View > Console View to display its contents. 


2 Right-click the Volume Resource object (volume_SERVER), then click Properties > Load to display 
the volume resource load script for the GroupWise volume. 


3 Following the pattern of the existing load commands, add load commands for the new 
instances of the agents you are setting up. Use Ctrl+C to copy and Ctrl+V to paste lines in the 
load script page. 


The results would be similar to the following example: 
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i Properties of GWYOL_SERVER 


cyshind add GWW-CLUSTER_GWVOL_SERVER 123.45.67.18 # NetWare 5.1 only 
NUDP ADD GW-CLUSTER_GWVOL_SERVER 123.45.67.18 

add secondary ipaddress 123.45.67.18 

search add gwolsystem 


SET AUTO RESTART AFTER ABEND = 2 
SET AUTO RESTART AFTER ABEND DELAY TIME = 0 





LOAD address space=devpoa GY/VOLASYSTEMIGWPOA @DEVELOPM.POA 
protection restart devpoa 

LOAD address space=provoimta GY/VOLASYSTEMIGWMTA @PROVO1.MTA 
protection restart provotmta 





4 Click Apply to save the modified load script. 
5 Click Unload 


6 Add corresponding unload commands for the new instances of the agents. 





i Properties of GWYVOL_SERVER 


unload address space = devpoa 
unload address space = provoimta 


del secondary ipaddress 123.45.67.18 
NUDP DEL GW-CLUSTER_GWVOL_SERVER 123.45.67.18 
cvshind del GVW-CLUSTER_GWVOL_SERVER 123.45.67.18 # NetWare 5.1 only 


dismount GWVOL force 
nss /forcedeactivate=GVWVOL 








Click Apply to save the modified unload script. 


You might want to review other properties of the Volume Resource object, such as the failover 
path on the Nodes page and the failover/failback/migration procedures on the Policies page, in 
light of the fact that an additional domain and/or post office now resides on the GroupWise 
volume. 


8 Change other Volume Resource properties as needed. 


9 Click OK to save the modified properties. 


10 


In the Cluster State View, take the GroupWise volume offline and then bring it online again to 
test the new startup files and the modified load and unload scripts. If you need assistance with 
these tasks, see Section 3.6, “Testing Your Clustered GroupWise System,” on page 54. 
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3.6 Testing Your Clustered GroupWise System 


After you have configured the GroupWise volume resources, you can test the load and unload scripts 
by bringing the GroupWise volume online and taking it offline again. 


1 In ConsoleOne, select the Cluster object, then click View > Cluster State. 





Cluster State | Event Log | HTML Report] 


p gw-cluster Epoch 1 Connected 


GW-CLUSTER1 GW-CLUSTER2 


Nodes Available (%) ; Resources Available (%) ~~) 
0 20 40 60 80 100 0 80 100 


Cluster Resource State | Location | a 


@ GWVOL_SERVER Offline | GW-CLUSTER1 | 
@ ILVOL_SERVER Running GW-CLUSTER1 ; 














The new GroupWise volume resource shows Offline in the State column. 
2 Click the new GroupWise volume resource, then click Online. 


The State column for the volume resource now displays Running. 





Cluster State | Event Log] HTML Report] 





p gw-cluster Epoch 1 Connected 
GW-CLUSTER1 GW-CLUSTER2 





Nodes Available (%) Resources Available ($ ~~ 
o 20 40 60 80 100 O 20 40 60 80 100 


Cluster Resource State | Location | aus 


@ GWVOL_SERVER Running GW-CLUSTER1 | 








@ ILVOL_SERVER Running | GWECLUSTER1 | 5; 











3 Observe the server console where the MTA and/or POA are loading to see that they start and run 
correctly. 


If you are using protected memory, you can use the protect ion command at the server console 
prompt to list all the address spaces on the node and what NLM programs are running in each 
one. 


4 Click the new GroupWise volume resource, then click Offline. 
The State column for the volume resource returns to Offline. 


5 Observe the server console where the MTA and/or POA are unloading to see that they shut 
down correctly. 


If you are using protected memory, you can use the protection command again to make sure 
that the address spaces used by the GroupWise agents are no longer present. 


6 Repeat Step 2 whenever you are ready to bring the new GroupWise volume resource online 
permanently. 
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3.7.1 


On NetWare 6.5, these actions can also be performed from your Web browser. See “Using Novell 
Remote Manager on NetWare 6.5” on page 56. 


7 Continue with Managing Your Clustered GroupWise System. 


Managing Your Clustered GroupWise System 


After you have set up a basic clustered GroupWise system, you should consider some long-term 
management issues. 
¢ Section 3.7.1, “Updating GroupWise Objects with Cluster-Specific Descriptions,” on page 55 
è Section 3.7.2, “Using Novell Remote Manager on NetWare 6.5,” on page 56 
+ Section 3.7.3, “Knowing What to Expect in MTA and POA Failover Situations,” on page 59 


Updating GroupWise Objects with Cluster-Specific Descriptions 


After setting up your clustered GroupWise system, while the cluster-specific information is fresh in 
your mind, you should record that cluster-specific information as part of the GroupWise objects in 
ConsoleOne so that you can easily refer to it later. Be sure to keep the information recorded in the 
GroupWise objects up to date if the configuration of your system changes. 

¢ “Recording Cluster-Specific Information for a Domain and Its MTA” on page 55 

¢ “Recording Cluster-Specific Information for a Post Office and Its POA” on page 55 


¢ “Recording Cluster-Specific Information for a Software Distribution Directory” on page 56 


Recording Cluster-Specific Information for a Domain and Its MTA 


To permanently record important cluster-specific information for the domain: 


1 In ConsoleOne, browse to and right-click the Domain object, then click Properties. 


2 Inthe Description field of the domain Identification page, provide a cluster-specific description of 
the domain, including the secondary IP address of its cluster-enabled volume and the cluster- 
unique port numbers used by its MTA. 


Click OK to save the domain description. 
Select the Domain object to display its contents. 
Right-click the MTA object, then click Properties. 


ow Aa O 


In the Description field of the MTA Identification page, record the secondary IP address of the 
cluster-enabled domain volume and the cluster-unique port numbers used by the MTA. 


This information appears on the MTA console, no matter which node in the cluster it is currently 
running on. 


7 Click OK to save the MTA description. 

8 Continue with Recording Cluster-Specific Information for a Post Office and Its POA. 
Recording Cluster-Specific Information for a Post Office and Its POA 
To permanently record important cluster-specific information for a post office: 


1 In ConsoleOne, browse to and right-click the Post Office object, then click Properties. 
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2 Inthe Description field of the post office Identification page, provide a cluster-specific 
description of the post office, including the secondary IP address of its cluster-enabled volume 
and the cluster-unique port numbers used by its POA. 


Click OK to save the post office description. 
Select the Post Office object to display its contents. 
Right-click the POA object, then click Properties. 


on Aà WwW 


In the Description field of the POA Identification page, record the secondary IP address of the 
cluster-enabled post office volume and the cluster-unique port numbers used by the POA. 


This information appears on the POA console, no matter which node in the cluster it is currently 
running on. 


7 Click OK to save the POA description. 


8 If necessary, continue with “Recording Cluster-Specific Information for a Software Distribution 
Directory” on page 56. 


or 


Skip to “Knowing What to Expect in MTA and POA Failover Situations” on page 59. 


Recording Cluster-Specific Information for a Software Distribution Directory 


To permanently record important cluster-specific information about a software distribution directory 
located on a cluster-enabled volume: 

1 In ConsoleOne, click Tools > System Operations > Software Directory Management. 

2 Select the software distribution directory, then click Edit. 


3 In the description field, record the secondary IP address of the cluster-enabled volume where 
the software distribution directory resides. 


4 Click OK, then click Close to save the software distribution directory description. 
5 Skip to “Knowing What to Expect in MTA and POA Failover Situations” on page 59. 


Using Novell Remote Manager on NetWare 6.5 


On NetWare 6.5, you can use Novell Remote Manager to manage many aspects of your GroupWise 
cluster from your Web browser. For instructions on setting up and accessing this useful network 
administration utility, see the NetWare 6.5 Novell Remote Manager Administration Guide at the Novell 
Documentation Web site (http://www.novell.com/documentation). Cluster management features are 
automatically added to Novell Remote Manager when you install Novell Cluster Services. 


After you have accessed Novell Remote Manager, you might find that many GroupWise cluster 
management tasks are easier to perform with Novell Remote Manager than with ConsoleOne. The 
following sections help you configure and manage the cluster using Novell Remote Manager: 


+ “Configuring Your GroupWise Cluster” on page 56 
+ “Managing Your GroupWise Cluster” on page 58 


Configuring Your GroupWise Cluster 


On the main Novell Remote Manager page: 


1 In the left frame, scroll down to the Clustering section, then click Cluster Config. 
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NetWare Remote Manager 
i: 


Protocol Information 
Java Application 
Information 
Manage Hardware 
Processors 
Disk / LAN Adapters 
PCI Devices 
Other Resources 
Manage eDirectory 
Access Tree Walker 
View eDirectory 


NetWare 6 Server Version 5.60, September 13, 2001 
entication (admin) 


e gw-cluster 


Node Name Number IP Address _ 
cw-clusrer12 123.456.78.91 
GW-CLUSTER? | AEST: 





Partitions 

NDS iMonitor Resources < 

HS Tews 4 1. Master IP_Address Resource 
Use Server Groups a cm 

Build Group EP 2, cwwor server 


Load Group File 
Access Other Servers 

Managed Server List 

Basic File Access 


E4 3. ILVOL_SERVER 
^ 4, iFolder Server 
N 5, Netscape Enterprise Server 


New Cluster Volume 


New Cluster Resource 








Health Monitors 


NDPS Broker Health 
NetWare Usage 

Usage Information 

Configuration 


Add Master Resource 








The Cluster Configuration page displays the cluster name, the nodes in the cluster, and the 
resources in the cluster. It also enables you to create new GroupWise Volume Resource objects 
(termed Cluster Volumes in the Novell Remote Manager interface). 


Click the cluster name to display the Cluster object properties: 


Cluster Configuration Fields: gw-cluster 
Revision 261 

IP Address 123.456.78.99 
Port Number 7023 

Quorum 

Membership 2 

Timeout 60 

Protocol 

Tolerance 8 

Heartbeat 1 

Master Watchdog 1 

Slave Watchdog 8 

Max Retransmit 30 


GIPC Stream 
Resource Priorities 
Email Reporting 


Click a linked item to edit the Cluster object properties. Click your browser’s Back button to 
return to the Cluster Configuration page. 


On the Cluster Configuration page, click a server to display the Server object properties: 


IP Address 123.456.78.99 
Node Number 0 
Back Delete 


Click a linked item to edit the Server object properties. Click Back or Delete to perform the 
specified action. 


On the Cluster Configuration page, click a GroupWise volume to display the Volume Resource 
object properties: 
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IP Address 123.456.78.90 


Loading Unloading 

Script Timeout Script Timeout 
600 600 

Policies Ignore No Start Auto FailOver Manual FailBack Disabled Master 
Quorum 

Nodes GW-CLUSTER1 , GW-CLUSTER2 , GW-CLUSTER3 , GW-CLUSTER4 

Back Delete 


Click a linked item to edit Volume Resource object properties. Click Back or Delete to perform the 
specified action. 


On the Cluster Configuration page, click New Cluster Volume to create anew GroupWise Volume 
Resource object, then follow the instructions to provide the information needed to create the 
new Cluster Volume object. 


Managing Your GroupWise Cluster 


On the main Novell Remote Manager page: 


1 In the left frame, scroll down to the Clustering section, then click Cluster Management. 


ovell NetVVare 6 Server Version 5.60, September 13, 2001 
thentication (admin) 










NetWare Remote Manager 
E 












Other Resources 
Manage eDirectory 
Access Tree Walker 


chee gas __BeginRetresh | Page Refresh Rate fio seconds z] 

NDS iMonitor 

DS Trace 
Use Server Groups Epoch 1 

Build Group 

Load Group File Nodes 
Access Other Servers 

Managed Server List Pl E E 

Shee Meee GW-CLUSTERI GW-CLUSTER2 GW-CLUSTERS 
Clustering 


Master_IP_Address_ Resource Running GW-CLUSTER1 1 10-30-2001 5:32:03 pm 





Cluster Config 








NDPS Broker Health GWVOL_SERVER Running GW-CLUSTER1 4 11-27-2001 1:53:39 pm 
NetWare Usage ILVOL_SERVER Running GW-CLUSTER1 1 10-30-2001 5:32:03 pm 

Usage Information É 

Configuration Event Log 








The Cluster Status page displays the nodes and volume resources in the cluster. The master node 
in the cluster is marked with a yellow ball. Status information is listed for each volume resource. 
You can set the refresh rate for the status information at the top of the Cluster Status page. 


Select a page refresh rate, then click Begin Refresh so that the page automatically refreshes at the 
selected rate. 


Click a cluster resource to bring it online, take it offline, or migrate it to another node. 


GW-CLUSTER2 & 
Offline | |GW-CLUSTER3 


GW-CLUSTER4 >| | Migrate | 


To take the currently running volume resource offline, click Offline. To migrate the volume 
resource, select a node from the drop-down list, then click Migrate. 
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3.7.3 


3.8 


3.9 


4 On the Cluster Resource page, click Event Log to view a list of cluster events. 


The event log can help you resolve problems with cluster functioning. 


Knowing What to Expect in MTA and POA Failover Situations 


In a failover situation, the agents might need to perform some database repair as they start on the 
new node. The time required depends on the size of the databases involved. 


Typically, the POA returns to full functionality faster than the MTA. This benefits GroupWise client 
users, who can reconnect to their mailboxes very quickly and probably do not notice if messages to 
users in other post offices are not delivered immediately. The only time a user would need to restart 
the GroupWise client would be if he or she was actually in the process of sending a message when the 
POA went down. Notify can continue running even if the connection to the POA becomes 
unavailable and then it reconnects automatically when the POA is again available. 


The MTA typically takes some time reestablishing the links to its post offices, other domains, and 
gateways, but this situation usually resolves itself in a few minutes without administrator 
intervention. If it does not, you can manually restart the MTA to speed up the process. 


In comparison to failover, migration typically takes longer because the agents methodically terminate 
their threads and close their databases as part of their normal shutdown procedure. However, as a 
result, no database repair is required when the agents start up again in their new location. 


Continue with What’s Next. 


What’s Next 


Now that you have at least one GroupWise domain and post office up and running in a clustering 
environment, you are ready to proceed with the rest of your GroupWise system setup by: 
+ Adding users to post offices. See “Users” in the GroupWise 8 Administration Guide. 


+ Setting up the GroupWise client software and helping users to get started using it. See “Client” 
in the GroupWise 8 Administration Guide. Also see the GroupWise 8 Windows Client User Guide. 


+ Connecting your clustered GroupWise system to the Internet. See Chapter 4, “Implementing the 
Internet Agent in a NetWare Cluster,” on page 63. 


¢ Providing access to users’ GroupWise mailboxes from their Web browsers. See Chapter 5, 
“Implementing WebAccess in a NetWare Cluster,” on page 81. 


+ Connecting your clustered GroupWise system to other e-mail systems through GroupWise 
gateways. See Chapter 6, “Implementing GroupWise Gateways in a NetWare Cluster,” on 
page 97. 


+ Monitoring the status of your clustered GroupWise system from your Web browser. See 
Chapter 7, “Monitoring a GroupWise System in a NetWare Cluster,” on page 99. 


¢ Backing up your clustered GroupWise system. See Chapter 8, “Backing Up a GroupWise System 
in a NetWare Cluster,” on page 101. 


Clustering Quick Checklists 


¢ Section 3.9.1, “GroupWise System Quick Checklist,” on page 60 
¢ Section 3.9.2, “Domain Quick Checklist,” on page 60 
+ Section 3.9.3, “Post Office Quick Checklist,” on page 61 
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3.9.1 GroupWise System Quick Checklist 


o 


o 


3.9.2 
m 


o 


Plan your new clustered GroupWise system. 


See Chapter 2, “Planning GroupWise in a NetWare Cluster,” on page 19. 
Cluster-enable the volumes where GroupWise domains and post offices will reside. 
See Section 3.1.2, “Cluster-Enabling Shared Volumes for Use with GroupWise,” on page 39. 
Make sure that short name resolution works throughout your network. 
See Section 3.1.3, “Configuring Short Name Resolution,” on page 40. 
Create the primary domain and initial post office in your new clustered GroupWise system. 
See Section 3.2, “Setting Up a New GroupWise System in a Cluster,” on page 42. 
Set up the agents for the primary domain and the initial post office. 
See Section 3.5, “Installing and Configuring the MTA and the POA in a Cluster,” on page 46. 
Modify the volume resource load script(s): 
+ Remove the trustmig command 
+ Add the search add command (optional) 


¢ If you will not run the agents in protected memory, add the set auto restart commands 
and the set developer option = off command 


+ Add the agent load command (s) 


¢ If you will run the agents in protected memory, add the address space parameter to the 
load command(s) and add a corresponding protection restart command for each 
address space 


See “Modifying the Volume Resource Load Script for the Agents” on page 48. 
Modify the volume resource unload script(s): 
+ Add the agent or address space unload command(s) 
+ Remove the trustmig command 
See “Modifying the Volume Resource Unload Script for the Agents” on page 49. 
Set up the volume failover path(s) and policies. 
See “Setting the Failover Path and Policies for the Agents” on page 50. 
Test your new clustered GroupWise system. 
See Section 3.6, “Testing Your Clustered GroupWise System,” on page 54. 


Record cluster-specific information in the properties pages of the GroupWise objects that the 
information pertains to. 


See Section 3.7, “Managing Your Clustered GroupWise System,” on page 55. 


Domain Quick Checklist 


Plan your new clustered domain. 


See Section 2.3, “Planning a New Clustered Domain,” on page 21. 
Cluster-enable the volume where the domain will reside. 


See Section 3.1.2, “Cluster-Enabling Shared Volumes for Use with GroupWise,” on page 39. 
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Make sure that short name resolution for the new domain volume works throughout your 
network. 


See Section 3.1.3, “Configuring Short Name Resolution,” on page 40. 
Create the new domain. 
See Section 3.3, “Creating a New Secondary Domain in a Cluster,” on page 43. 
Set up the MTA for the new domain. 
See Section 3.5, “Installing and Configuring the MTA and the POA in a Cluster,” on page 46. 
Modify the domain volume resource load script: 
+ Remove the trustmig command 
+ Add the search add command (optional) 


¢ If you will not run the MTA in protected memory, add the set auto restart commands 
and the set developer option = off command 


+ Add the MTA load command 


+ If you will run the MTA in protected memory, add the address space parameter to the 
MTA load command and add a corresponding protection restart command for the 
address space 


See “Modifying the Volume Resource Load Script for the Agents” on page 48. 
Modify the domain volume resource unload script: 
+ Add the MTA or address space unload command 
+ Remove the trustmig command 
See “Modifying the Volume Resource Unload Script for the Agents” on page 49. 
Set up the domain volume failover path and policies. 
See “Setting the Failover Path and Policies for the Agents” on page 50. 
Test your new clustered domain. 
See Section 3.6, “Testing Your Clustered GroupWise System,” on page 54. 


Record cluster-specific information in the properties pages of the GroupWise objects that the 
information pertains to. 


See Section 3.7, “Managing Your Clustered GroupWise System,” on page 55. 


3.9.3 Post Office Quick Checklist 


o 


o 


Plan your new clustered post office. 


See Section 2.4, “Planning a New Clustered Post Office,” on page 22. 
Cluster-enable the volume where the post office will reside. 
See Section 3.1.2, “Cluster-Enabling Shared Volumes for Use with GroupWise,” on page 39. 


Make sure that short name resolution for the new post office volume works throughout your 
network. 


See Section 3.1.3, “Configuring Short Name Resolution,” on page 40. 
Create the new post office. 

See Section 3.4, “Creating a New Post Office in a Cluster,” on page 44. 
Set up the POA for the new post office. 
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See Section 3.5, “Installing and Configuring the MTA and the POA in a Cluster,” on page 46. 


Add the /ip startup switch to the POA startup file in order to provide the secondary IP address 
of the post office volume. If you are running the POA in protected memory, add the /user and / 
password startup switches so the POA can access the volume. 


See “Editing Clustered Agent Startup Files” on page 47. 
Modify the post office volume resource load script: 

+ Remove the trustmig command 

+ Add the search add command (optional) 


¢ If you will not run the POA in protected memory, add the set auto restart commands 
and the set developer option = off command 


+ Add the POA load command 


¢ If you will run the POA in protected memory, add the address space parameter to the 
POA load command and add a corresponding protection restart command for the 
address space 


See “Modifying the Volume Resource Load Script for the Agents” on page 48. 
Modify the post office volume resource unload script: 
+ Add the POA or address space unload command 
+ Remove the trustmig command 
See “Modifying the Volume Resource Unload Script for the Agents” on page 49. 
Set up the post office volume failover path and policies. 
See “Setting the Failover Path and Policies for the Agents” on page 50. 
Test your new clustered post office. 
See Section 3.6, “Testing Your Clustered GroupWise System,” on page 54. 


Record cluster-specific information in the properties pages of the GroupWise objects that the 
information pertains to. 


See Section 3.7, “Managing Your Clustered GroupWise System,” on page 55. 
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Implementing the Internet Agent ina 
NetWare Cluster 


You should already have set up at least a basic GroupWise system, as described in Chapter 2, 
“Planning GroupWise in a NetWare Cluster,” on page 19 and Chapter 3, “Setting Up a Domain and 
Post Office in a NetWare Cluster,” on page 39. As part of this process, the “System Clustering 
Worksheet” on page 33 and the “IP Address Worksheet” on page 35 were filled out. If you do not 
have access to the filled-out worksheets, print the worksheets now and fill in the clustering and 
network address information as it currently exists on your system. You need this information as you 
implement the Internet Agent in a cluster. 

+ Section 4.1, “Planning the Internet Agent in a Cluster,” on page 63 

+ Section 4.2, “Setting Up the Internet Agent in a Cluster,” on page 67 

+ Section 4.3, “Managing the Internet Agent in a Cluster,” on page 76 

+ Section 4.4, “Internet Agent Clustering Worksheet,” on page 77 


+ Section 4.5, “Internet Agent Quick Checklist,” on page 79 


Planning the Internet Agent in a Cluster 


A main system configuration difference between a GroupWise system in a clustering environment 
and a GroupWise system in a regular environment is that you need to create a separate domain to 
house each GroupWise gateway, including the Internet Agent. 


The Section 4.4, “Internet Agent Clustering Worksheet,” on page 77 lists all the information you need 
as you set up the Internet Agent in a clustering environment. You should print the worksheet and fill 
it out as you complete the tasks listed below: 

¢ Section 4.1.1, “Planning a Domain for the Internet Agent,” on page 64 

+ Section 4.1.2, “Deciding Whether to Cluster-Enable the Internet Agent Volume,” on page 64 


¢ Section 4.1.3, “Determining an Appropriate Failover Path for the Internet Agent Volume,” on 
page 64 


¢ Section 4.1.4, “Planning a Secondary IP Address and Cluster-Unique Port Numbers for the 
Internet Agent and Its MTA,” on page 65 


è Section 4.1.5, “Preparing Your Firewall for the Internet Agent,” on page 65 
+ Section 4.1.6, “Deciding Where to Install the Internet Agent and Its MTA,” on page 66 


¢ Section 4.1.7, “Deciding Whether to Run the Internet Agent and Its MTA in Protected Memory,” 
on page 66 


è Section 4.1.8, “Planning the MTA Installation,” on page 66 
¢ Section 4.1.9, “Planning the Internet Agent Installation,” on page 67 
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4.1.1 


4.1.2 


4.1.3 


Planning a Domain for the Internet Agent 


The considerations involved in planning a domain for the Internet Agent are much the same as 
planning any other domain. In preparation, review “Planning a New Domain”, then print and fill out 
the “Domain Worksheet” in “Domains” in the GroupWise 8 Administration Guide. 


Keep in mind the following cluster-specific details: 


¢ When you specify the location for the domain directory on the Domain Worksheet, include the 
shared volume where you want the domain directory to reside. 


+ Do not concern yourself with the GroupWise agent information on the Domain Worksheet. You 
can stop with item 10. You will plan the MTA installation later. 


When you have completed the Domain Worksheet, transfer the key information from the Domain 
Worksheet to the Internet Agent Clustering Worksheet. 


INTERNET AGENT CLUSTERING WORKSHEET 


Under Item 1: Shared Volume for Internet Agent, transfer the domain location to the Internet Agent 
Clustering Worksheet. 


Under Item 2: Internet Agent Domain Name, transfer the domain name and database directory to the 
Internet Agent Clustering Worksheet. 


Deciding Whether to Cluster-Enable the Internet Agent Volume 


You should plan to cluster-enable the shared volume where the Internet Agent domain will reside. 
For a review of the benefits of cluster-enabling volumes, see Section 2.6, “Deciding Whether to 
Cluster-Enable the Shared Volumes Used by GroupWise,” on page 23, which describes the issues in 
the context of planning MTA and POA installations. 


INTERNET AGENT CLUSTERING WORKSHEET 
Under Item 1: Shared Volume for Internet Agent, mark Yes under Cluster Enabled?. 
Cluster-enabling relies on successful short name resolution throughout your system. Review 


Section 2.7, “Ensuring Successful Name Resolution for GroupWise Volumes,” on page 25, which 
describes the issues in the context of planning MTA and POA installations. 


Determining an Appropriate Failover Path for the Internet Agent 
Volume 


As with the MTA and the POA, you need to decide which nodes in the cluster would be appropriate 
locations for the Internet Agent volume to fail over to. For a review of failover paths, see 
“Determining Appropriate Failover Paths for the Agents” on page 29, which describes the issues in 
the context of planning MTA and POA installations. 


INTERNET AGENT CLUSTERING WORKSHEET 


Under Item 3: Internet Agent Failover Path, list the nodes that you want to have in the Internet Agent 
volume failover path. 
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4.1.4 


4.1.5 


Planning a Secondary IP Address and Cluster-Unique Port Numbers 
for the Internet Agent and Its MTA 


As with the MTA and the POA, the Internet Agent needs a secondary IP address and cluster-unique 
port numbers. As part of planning to install the MTA and POA, you should already have determined 
the secondary IP address and cluster-unique port numbers for the Internet Agent and its MTA as you 
filled out the “IP Address Worksheet” on page 35. If you do not have a filled-out copy of this 
worksheet for your system, print it now and fill in current system information. 


INTERNET AGENT CLUSTERING WORKSHEET 


Under Item 5: MTA Network Information, transfer the MTA secondary IP address and cluster-unique 
port numbers from the Internet Agent section of the IP Address Worksheet to the Internet Agent 
Clustering Worksheet. 


Under Item 1: Shared Volume for Internet Agent, copy the MTA secondary IP address under Cluster 
Volume IP Address as well, because they are the same. 


Under Item 7: Internet Agent Network Information, transfer the Internet Agent secondary IP address 
(the same as for its MTA) and the cluster-unique Internet Agent port number from the Internet Agent 
section of the IP Address Worksheet to the Internet Agent Clustering Worksheet. 


Preparing Your Firewall for the Internet Agent 
The Internet Agent receives incoming messages on the secondary IP address of the Internet Agent 


domain volume. Your firewall configuration must be modified to allow inbound TCP/IP traffic from 
the Internet to the Internet Agent secondary IP address on the following standard ports: 


Table 4-1 Standard Ports 


Protocol Standard Port 
IMAP4 143 

LDAP 389 

POP3 110 

SMTP 25 


By default, the Internet Agent sends outgoing messages on the primary IP address of the server where it 
is running. If you decide to use this default configuration, your firewall must be configured to allow 
outbound TCP/IP traffic from all nodes in the Internet Agent volume failover path. 


If the Internet Agent has a large number of nodes on its failover path, you could configure the 
Internet Agent to send outgoing messages to a relay host, which would then send them out through 
the firewall using its own IP address rather than the address of the particular node where the Internet 
Agent was running. This reduces the amount of modification to your firewall required to set up the 
Internet Agent. However, if the relay host goes down, outgoing messages are delayed. 


As another alternative, you can configure the Internet Agent to use its secondary IP address for 
sending as well as receiving messages. Setup instructions for this configuration are provided in 
“Forcing Use of the Internet Agent Secondary IP Address” on page 75, which you can complete after 
installing the Internet Agent. 
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4.1.6 


4.1.7 


4.1.8 


In preparation for installing the Internet Agent, configure your firewall as needed to handle the 
Internet Agent’s use of primary and secondary IP addresses when sending and receiving messages. 


Deciding Where to Install the Internet Agent and Its MTA 


As with the MTA and the POA, you can choose to install the Internet Agent and its MTA to the 

sys: \system directory of each node or to a vol: \system directory on the Internet Agent volume. 
For a discussion of these alternatives, see “Deciding Where to Install the Agent Software” on page 29, 
which describes the issues in the context of planning MTA and POA installations. If you only have 
one Internet Agent for your GroupWise system with several servers in its failover path, it is an easy 
choice: Install it once to a vol: \system directory on the Internet Agent volume. 


INTERNET AGENT CLUSTERING WORKSHEET 


Under Item 4: MTA Installation Location and Item 6: Internet Agent Installation Location, mark whether 
you will install the Internet Agent and its MTA to a vol: \system directory on the Internet Agent 
volume or to sys: \system on each node in the cluster. If necessary, specify where the MTA startup 
file and the Internet Agent configuration file will be stored. 


Deciding Whether to Run the Internet Agent and Its MTA in Protected 
Memory 


As with the MTA and the POA, you can choose whether to run the Internet Agent in protected 
memory. For a review of the benefits of protected memory, see “Deciding Whether to Run the Agents 
in Protected Memory” on page 31, which describes the issues in the context of planning MTA and 
POA installations. 


You might think that protected memory is not necessary if you have only one Internet Agent for your 
GroupWise system because it could never fail over to a node where another Internet Agent was 
running. However, because the Internet Agent in a cluster is installed into its own domain with its 
own MTA, this MTA could fail over to anode where another MTA was already running. Therefore, it 
is safest to load the MTA into protected memory. Loading the Internet Agent into protected memory 
is also recommended. Load each agent into its own memory space and mark each memory space as 
restartable. 


INTERNET AGENT CLUSTERING WORKSHEET 


Under Item 8: Load Internet Agent and Its MTA in Protected Memory?, mark whether you need to run 
the Internet Agent and its MTA in protected memory. If you do, provide a protected memory address 
space name for each agent. 


Planning the MTA Installation 


Follow the instructions in “Planning the NetWare Agent Installation” on page 32, then return to this 
point. After you follow the instructions, you have a filled-out NetWare Agent Worksheet to use when 
you install the MTA. 





IMPORTANT: Do not install the NetWare MTA until you are instructed to do so in Section 4.2, 
“Setting Up the Internet Agent in a Cluster,” on page 67. 
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4.1.9 


4.2 


4.2.1 


Planning the Internet Agent Installation 


Aside from the cluster-specific issues discussed in the preceding sections, the considerations 
involved in planning to install the Internet Agent are the same in a clustering environment as for any 
other environment. Review the installation instructions in “NetWare and Windows: Installing the 
Internet Agent Software” in “Installing the GroupWise Internet Agent” in the GroupWise 8 Installation 
Guide. You might want to print this section and write down the types of planning information you 
have provided on worksheets in other sections. You will need this information as you install the 
Internet Agent in your cluster. 





IMPORTANT: Do not install the Internet Agent software until you are instructed to do so in 
Section 4.2, “Setting Up the Internet Agent in a Cluster,” on page 67. 





Setting Up the Internet Agent in a Cluster 


You should already have reviewed Section 4.1, “Planning the Internet Agent in a Cluster,” on page 63 
and filled out the Section 4.4, “Internet Agent Clustering Worksheet,” on page 77. You are now ready 
to complete the following tasks to set up the Internet Agent in a clustering environment: 

+ Section 4.2.1, “Cluster-Enabling a Shared Volume for Use with the Internet Agent,” on page 67 

+ Section 4.2.2, “Creating a Domain for the Internet Agent,” on page 68 

+ Section 4.2.3, “Installing the MTA for the Internet Agent Domain,” on page 68 

+ Section 4.2.4, “Installing and Configuring the Internet Agent in a Cluster,” on page 68 

+ Section 4.2.5, “Testing the Clustered Internet Agent,” on page 75 


Cluster-Enabling a Shared Volume for Use with the Internet Agent 


To cluster-enable the Internet Agent shared volume: 


1 Complete the cluster-enabling steps in the applicable section of the cluster documentation for 
your version of NetWare, as listed in Chapter 1, “Introduction to GroupWise 8 and Novell 
Cluster Services on NetWare,” on page 17. 


The Internet Agent Clustering Worksheet provides the volume to cluster-enable, the cluster- 
enabled volume IP address, and the failover path for the Internet Agent volume. 


For a review of the new Novell eDirectory objects that are created when you cluster-enable a 
shared volume, see Section 2.6, “Deciding Whether to Cluster-Enable the Shared Volumes Used 
by GroupWise,” on page 23. 

If you have installed the latest version of ConsoleOne and the Novell Cluster Services snap-in, 
you can rename the cluster-related objects in case your DNS name server cannot resolve object 
names that include the underscore (_) character. 


2 To ensure successful short name resolution, add entries for the Internet Agent virtual server to 
support your preferred methods of short name resolution, as described in “Configuring Short 
Name Resolution” on page 40. 


3 To ensure that the Internet Agent has incoming and outgoing access to the Internet, make sure 
your firewall is properly configured, as described in “Preparing Your Firewall for the Internet 
Agent” on page 65. 


4 Continue with Creating a Domain for the Internet Agent. 
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4.2.2 


4.2.3 


4.2.4 


Creating a Domain for the Internet Agent 


The Internet Agent domain will be a secondary domain. To create it, follow the instructions in 
Section 3.3, “Creating a New Secondary Domain in a Cluster,” on page 43, taking your information 
from the Internet Agent Clustering Worksheet, rather than the System Clustering Worksheet, then 
return to this point. 


Do not create any post offices in the Internet Agent domain. 


Continue with Installing the MTA for the Internet Agent Domain. 


Installing the MTA for the Internet Agent Domain 


The MTA for the Internet Agent domain can be installed just like any other MTA in your clustered 
GroupWise system. Follow the instructions in “Installing the Agent Software in a Cluster” on 
page 46, then return to this point. 


You do not need to edit the MTA startup file. You do not need to modify the Volume Resource 
properties until after you have installed the Internet Agent. 


Continue with Installing and Configuring the Internet Agent in a Cluster. 


Installing and Configuring the Internet Agent in a Cluster 


After you have created a domain for the Internet Agent and installed the MTA for that domain, you 
are ready to install and configure the Internet Agent. 
¢ “Installing the Internet Agent Software in a Cluster” on page 68 


+ “Configuring the Internet Agent Volume Resource to Load and Unload the Internet Agent and 
Its MTA” on page 69 


¢ “Enabling Internet Addressing for Your Clustered GroupWise System” on page 73 
¢ “Verifying Internet Agent Object Properties” on page 74 


Installing the Internet Agent Software in a Cluster 


1 Map a drive to the Internet Agent volume (Internet Agent Clustering Worksheet item 1). 


The Internet Agent volume name will be cluster_volume. For assistance with mapping a drive toa 
cluster-enabled volume, see “Configuring Short Name Resolution” on page 40. 


2 If you selected vol: \system on Internet Agent Volume as the Internet Agent installation 
location (Internet Agent Clustering Worksheet item 6), create the vol: \system directory on the 
Internet Agent volume accessed in Step 1. 


or 


If you selected sys: \system on Each Node, decide which node you will install the Internet 
Agent to first, then map a drive to sys: \system on that node. 


3 Start the Internet Agent Installation program and install the NetWare Internet Agent, following 
the steps provided in “NetWare and Windows: Installing the Internet Agent Software” in 
“Installing the GroupWise Internet Agent” in the GroupWise 8 Installation Guide. Keep in mind 
the following cluster-specific details: 


¢ Use the notes you made during “Planning the Internet Agent Installation” on page 67 to fill 
in the fields during the Internet Agent installation process. 
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¢ In the Installation Path dialog box, be sure to browse through the drive you mapped to the 
location you chose in Step 2 above. Deselect Update AUTOEXEC File and select Configure 
GroupWise Agents for Clustering. 


¢ In the GroupWise Domain dialog box, be sure to browse through the drive you mapped in 
Step 1 to the domain directory (Internet Agent Clustering Worksheet item 2). 


+ The Internet Agent Installation program creates the gwia.ncf file, which includes the load 
command for the Internet Agent. You need this information later when you create the load 
script for the Volume Resource object. 


4 If you need to install the Internet Agent to sys: \system to each node in the cluster: 
4a Repeat Step 3, mapping new drives as needed. 


4b If you marked Yes for Consolidate Multiple Configuration Files on Internet Agent Volume? 
(under Internet Agent Clustering Worksheet item 6), copy the gwia. cfg file to the planned 
location, then delete it from the sys: \system directories to avoid future confusion. 


5 Make sure you have completed all the tasks described in “Installing the GroupWise Internet 
Agent” in the GroupWise 8 Installation Guide. 


The Internet Agent starts automatically immediately after Installation. 
6 Stop each Internet Agent you have installed before configuring it for clustering. 


7 Continue with Configuring the Internet Agent Volume Resource to Load and Unload the 
Internet Agent and Its MTA. 


Configuring the Internet Agent Volume Resource to Load and Unload the Internet 
Agent and Its MTA 


The properties of the Volume Resource object define how the Internet Agent volume functions within 
the cluster, how NLM programs are loaded and unloaded, and how failover and failback situations 
are handled. Complete the following tasks for the Internet Agent volume: 

¢ “Modifying the Volume Resource Load Script for the Internet Agent” on page 69 

e “Modifying the Volume Resource Unload Script for the Internet Agent” on page 71 

+ “Setting the Failover Path and Policies for the Internet Agent” on page 72 


Modifying the Volume Resource Load Script for the Internet Agent 
The volume resource load script executes whenever the Internet Agent volume comes online. 
To set up the load script: 


1 In ConsoleOne, browse to and select the Cluster object. 
If necessary, click View > Console View to display its contents. 


2 Right-click the Volume Resource object (volume_SERVER), then click Properties > Load to display 
the default volume resource load script for the Internet Agent volume. 


The next step assumes that this is the first time you have edited this load script. If other 
GroupWise agents are already running from this volume, some of the modifications have 
already been made. 


3 Make the following changes to the default load script: 


+ Remove the trustmig command. It is not necessary to migrate trustees for the Internet 
Agent volume. Removing this line helps the load script to execute faster. 
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+ If you selected vol: \system on Internet Agent volume as the installation location (Internet 


Agent Clustering Worksheet items 4 and 6), add a search add command to add the new 
vol: \system directory to the server search path. 


search add volume:\system 


If you selected sys: \system on each node as the installation location (Internet Agent 
Clustering Worksheet items 4 and 6) but you are storing the MTA startup file and the 
Internet Agent configuration file on the Internet Agent volume, add that location to the 
server search path. 


If you marked No under Load Internet Agent and Its MTA in Protected Memory? (Internet 
Agent Clustering Worksheet item 8), add the following abend recovery options: 


set auto restart after abend = 2 

set auto restart after abend delay time = 0 
set auto restart down timeout = 60 

set developer option = off 


These settings provide the best possible handling of GroupWise databases in the event that 
an abend should occur within the cluster. 


Transfer the MTA load command from the grpwise.ncf file located in the vol: \system 
directory into the load script. Use Ctrl+C and Ctrl+V to copy and paste text into the load 
script page. Then delete or rename the grpwise.ncf file to avoid future confusion. 


load volume:\system\gwmta.nlm @domain.mta 


Transfer the Internet Agent load command from the gwia.ncf file located in the 
vol:\system directory into the load script. Use Ctrl+C and Ctrl+V to copy and paste text 
into the load script page. Then delete or rename the gwia .ncf file to avoid future confusion. 


load volume:\system\gwia.nlm @gwia.cfg 


If you marked Yes under Load Internet Agent and Its MTA in Protected Memory? (Internet 
Agent Clustering Worksheet item 8), add the address space parameter to the load 
commands to specify the protected address space where the Internet Agent and its MTA 
will run. Add a protection restart command for the address space name. 


load address space=addr_space_ name 

~~ volume: \system\gwmta.nlm @domain.mta 
load address space=addr_space_ name 

~~ volume: \system\gwia.nlm @gwia.cfg 
protection restart addr_space name 


The result would look similar to the following example: 
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Properties of GWYOL_SERVER |x} 


IP Address | Load Unload | Policies | Nodes | NDS Rights ~ | Other | Rights to Files and Fold 
L Cluster Resource Load Script 


Script 





nss /activate=GVWVOL a 
mount GWWOL VOLID=254 

cyshind add GWW-CLUSTER_GWVOL_SERVER 123.45.67.18 # NetWare 5.1 only 

NUDP ADD GWV-CLUSTER_GWVOL_SERVER 123.45.67.18 

add secondary ipaddress 123.45.67.18 

search add gwvolsystem 


SET AUTO RESTART AFTER ABEND = 2 

SET AUTO RESTART AFTER ABEND DELAY TIME = 0 
SET AUTO RESTART DOWN TIMEOUT = 60 

SET DEVELOPER OPTION = OFF 


LOAD address space=gwia GYVVOLASYSTEMIGWWMTA @PROVO1.MTA 
LOAD DELAY, DELAY 10 

LOAD address space=gwia GWWVOLASYSTEMIGWIA @GWIA.CFG 
protection restart gwia 


i| » 
Timeout (secs) |600 








Page Options... | OK | Cancel [C sn] Help | 








NOTE: The set commands are needed in the load script only when the MTA and the Internet 
Agent are not running in protected memory. The address space parameters are needed in the 
load commands only when the MTA and the Internet Agent are running in protected memory. 





For another example of a load script, see TID 7006193: Running the GroupWise Agents in a Non- 
Protected Address Space on a NetWare Cluster in the Novell Knowledgebase (http:// 
www.novell.com/support). 


4 Click Apply to save the load script. 


5 If necessary, click OK to confirm that you must offline and then online the volume resource in 
order for the changes to take effect. 


6 Continue with Modifying the Volume Resource Unload Script for the Internet Agent. 


Modifying the Volume Resource Unload Script for the Internet Agent 


The volume resource unload script executes whenever the Internet Agent volume goes offline. 
Programs should be unloaded in the reverse order of how they were loaded. This ensures that 
supporting programs are not unloaded before programs that rely on them in order to function 
properly. 

To set up the unload script: 


1 In ConsoleOne, in the properties pages for the Volume Resource object (volume_SERVER), click 
Unload to display the default volume resource unload script. 


The next step assumes that this is the first time you have edited this unload script. If other 
GroupWise agents are already running from this volume, some of the modifications have 
already been made. 


2 Make the following changes to the default unload script: 


¢ If you marked Yes under Load Internet Agent and Its MTA in Protected Memory? (Internet 
Agent Clustering Worksheet item 8), add an unload address space command and an 
unload kill address space command to ensure that the address space is completely 
cleaned up. 


unload address space=addr_space_name 
unload kill address space=addr_space_name 
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If your system seems to be trying to kill the address space before the Internet Agent and its 
MTA have been completely unloaded, resulting in the agents hanging in the unloading 
state, set a delay of several seconds before issuing the unload kill address space 
command to allow the Internet Agent and its MTA adequate time to unload completely. The 
length of the delay varies from system to system; ten seconds is a good starting place. 


unload address space=addr_space_name 
delay 10 
unload kill address space=addr_space_name 


¢ If you marked No under Load Internet Agent and Its MTA in Protected Memory? (Internet 
Agent Clustering Worksheet items 8), create an unload command parallel to each load 
command that you placed in the load script. 


unload gwia.nlm 
unload gwmta.nlm 


+ Remove the trustmig command just like you did in the load script. 


The result would look similar to the following example: 


Properties of GWYOL_SERVER |x} 
IP Address | Load Unload SSS | Policies | Nodes | NDS Rights ~ | Other | Rights to Files and Ford 


Script 





unload address space = gwia a 


del secondary ipaddress 123.45.67.18 

NUDP DEL GW-CLUSTER_GWWOL_SERVER 123.45.67.18 

cysbind del GW-CLUSTER_GWWVOL_SERVER 123.45.67.18 # NetWare 5.1 only 
dismount GWVOL force 

nss /forcedeactivate=GVWVOL 





Ki » 
Timeout (secs) |600 








Page Options... | OK | Cancel [C ae ] Help | 


3 Click Apply to save the unload script. 


4 If necessary, click OK to confirm that you must offline and then online the volume resource in 
order for the changes to take effect. 


5 Continue with Setting the Failover Path and Policies for the Internet Agent. 
Setting the Failover Path and Policies for the Internet Agent 
To modify the failover path and policies for the Internet Agent volume resource: 


1 In ConsoleOne, in the properties pages for the Volume Resource object (volume_SERVER), click 
Nodes to display the default failover path for the Internet Agent volume resource. 
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Properties of GWYOL_SERVER |x} 


NDS Rights v | Other | Rights to Files and! 








Unassigned Assigned 

 GW-CLUSTER1 
 GW-CLUSTER2 
ÉP GW-CLUSTER3 
 GW-CLUSTER4 
































Page Options... | OK | Cancel [C ae ] Help | 


2 Arrange the nodes in the cluster into the desired failover path for the Internet Agent volume 
(Internet Agent Clustering Worksheet item 3). 


3 Click Apply to save the failover path. 
4 Click Policies to display the default start, failover, and failback policies. 





Properties of GWYOL_SERYER | x} 





I Ignore Quorum 


Start Mode 
@ Manual C Auto 





Failover Mode 
C Manual © Auto 


;Failback Mode 
C Manual C Auto © Disable 

















Page Options... | ok | Cancel | ee Help | 


The default policy settings are often appropriate. By default, a volume resource: 
¢ Fails over automatically if the node it is running on fails 
¢ Starts automatically on the next node in its failover path 


¢ Continues running at its failover location, even after its most preferred node is again 
available 


If you are considering changing these defaults, see the applicable section about failover and 
failback modes in the cluster documentation for your version of NetWare, as listed in Chapter 1, 
“Introduction to GroupWise 8 and Novell Cluster Services on NetWare,” on page 17. 


5 Click OK when you are finished editing the Internet Agent volume resource properties. 


6 Continue with Enabling Internet Addressing for Your Clustered GroupWise System. 


Enabling Internet Addressing for Your Clustered GroupWise System 
Setting up Internet addressing for a clustered Internet Agent is no different from setting it up for an 


Internet Agent in a any other environment. Follow the instructions in “Enabling Internet 
Addressing” in “System” in the GroupWise 8 Administration Guide, then return to this point. 
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Verifying Internet Agent Object Properties 


During installation of the Internet Agent, the Internet Agent object should have been configured 
correctly. However, it can be helpful to verify certain cluster-specific information in order to 
familiarize yourself with the configuration of a clustered Internet Agent. 

+ “Accessing Internet Agent Object Properties” on page 74 

¢ “Verifying the Reference to the Volume Resource” on page 74 

¢ “Verifying the Reference to the Virtual Server” on page 74 

¢ “Verifying Post Office Links” on page 74 

¢ “Forcing Use of the Internet Agent Secondary IP Address” on page 75 


Accessing Internet Agent Object Properties 


1 In ConsoleOne, browse to and select the Internet Agent domain in order to display its contents. 
2 Right-click the Internet Agent object, then click Properties. 


3 Continue with Verifying the Reference to the Volume Resource. 


Verifying the Reference to the Volume Resource 
In the Internet Agent object properties pages: 


1 Click SMTP/MIME > Settings. 
2 Verify the contents of the Hostname/DNS "A Record” Name field. 


It displays the hostname as currently configured in DNS. It should match the Volume Resource 
object name (volume_SERVER) of the Internet Agent volume, not the name of a physical server in 
the cluster. 


3 Make changes if necessary. 


4 Continue with Verifying the Reference to the Virtual Server. 


Verifying the Reference to the Virtual Server 
In the Internet Agent object properties pages: 


1 Click Server Directories. 


2 Verify that the displayed directories match the virtual server name (cluster_volume_SERVER) 
associated with the Volume Resource object, not the name of a physical server in the cluster. 


3 Make changes if necessary. 
4 Continue with Verifying Post Office Links. 


Verifying Post Office Links 
In the Internet Agent object properties pages: 


1 Click Post Office Links. 


2 Verify that the Access Mode column displays C/S (for client/server mode) for all post offices 
serviced by the Internet Agent. 


3 Verify that the Links column displays the secondary IP addresses of the GroupWise volumes 
where post offices reside, not the IP addresses of any physical servers in the cluster. 
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4 Make changes if necessary. 
5 Continue with Forcing Use of the Internet Agent Secondary IP Address. 


Forcing Use of the Internet Agent Secondary IP Address 


If you want the Internet Agent to send outgoing messages on its secondary IP address, rather than 
using the default of its primary IP address: 
1 Click GroupWise > Network Address. 


2 Inthe TCP/IP Address field, provide the secondary IP address (under Internet Agent Clustering 
Worksheet item 1) for the Internet Agent to use for sending outgoing messages. 


3 Click SMTP/MIME, then click Settings. 

4 Select Bind to TCP/IP Address at Connection Time. 

5 Click OK. 

6 Continue with Testing the Clustered Internet Agent. 


4.2.5 Testing the Clustered Internet Agent 


After you have configured the Internet Agent volume resource, you can test the load and unload 
scripts by bringing the Internet Agent volume online and taking it offline again. 


1 In ConsoleOne, select the Cluster object, then click View > Cluster State. 





Cluster State | Event Log] HTML Report] 
p gw-cluster Epoch 1 Connected 


GW-CLUSTER1 GW-CLUSTER2 


atl 


Dud 
100 


R Available (%) p Resources Available (%) 





Cluster Resource State | Location | #Lives 
2 


@ GWVOL_SERVER Offline | GW-CLUSTER1 | 
@ ILVOL_SERVER Running GW-CLUSTER1 | 2 











The new Internet Agent volume resource shows Offline in the State column. 


2 Click the new Internet Agent volume resource, then click Online. 





Cluster State | Event Lag] HTML Report] 
p gw-cluster Epoch 1 Connected 


GW-CLUSTER1 GW-CLUSTER2 


Nodes Available (%) Resources Available ($) ~~} 
0O 20 40 60 80 100 o 20 40 60 80 100 


Cluster Resource State | Location | 


@ GWVOL_SERVER Running | GW-CLUSTER1 | 
@ ILVOL_SERVER Running | GWECLUSTER1 | 














The State column for the volume resource now displays Running. 
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4.3 


4.3.1 


3 Observe the server console where the Internet Agent and its MTA are loading to see that they 
start and run correctly. 


If you are using protected memory, you can use the protection command at the server console 
prompt to list all the address spaces on the node and what NLM programs are running in each 
one. 


4 Click the new Internet Agent volume resource, then click Offline. 
The State column for the volume resource returns to Offline. 


5 Observe the server console where the Internet Agent and its MTA are unloading to see that they 
shut down correctly. 


If you are using protected memory, you can use the protection command again to make sure 
that the address space used by the Internet Agent and its MTA is no longer present. 


6 Repeat Step 2 whenever you are ready to bring the new Internet Agent volume resource online 
permanently. 


On NetWare 6.5, these actions can also be performed from your Web browser. See “Using Novell 
Remote Manager on NetWare 6.5” on page 56. 


7 Continue with Managing the Internet Agent in a Cluster. 


Managing the Internet Agent in a Cluster 


After you have installed the Internet Agent in a cluster, you should consider some long-term 
management issues. 
+ Section 4.3.1, “Updating GroupWise Objects with Cluster-Specific Descriptions,” on page 76 
¢ Section 4.3.2, “Knowing What to Expect in an Internet Agent Failover Situation,” on page 77 


Updating GroupWise Objects with Cluster-Specific Descriptions 


After installing the Internet Agent in your clustered GroupWise system, while the cluster-specific 
information is fresh in your mind, you should record that cluster-specific information as part of the 
GroupWise objects in ConsoleOne so that you can easily refer to it later. Be sure to update the 
information recorded in the GroupWise objects if the configuration of your system changes. 


+ “Recording Cluster-Specific Information about the Internet Agent Domain and Its MTA” on 
page 76 


+ “Recording Cluster-Specific Information about the Internet Agent” on page 77 


Recording Cluster-Specific Information about the Internet Agent Domain and Its 
MTA 


To permanently record important cluster-specific information for the Internet Agent domain: 


1 In ConsoleOne, browse to and right-click the Domain object, then click Properties. 


2 Inthe Description field of the Internet Agent domain Identification page, provide a cluster- 
specific description of the Internet Agent domain, including the secondary IP address of its 
cluster-enabled volume and the cluster-unique port numbers used by its MTA. 


3 Click OK to save the Internet Agent domain description. 
4 Select the Internet Agent Domain object to display its contents. 
5 Right-click the MTA object, then click Properties. 
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4.3.2 


4.4 


6 Inthe Description field of the MTA Identification page, record the secondary IP address of the 
cluster-enabled Internet Agent domain volume and the cluster-unique port numbers used by the 
MTA. 


This information appears on the MTA console, no matter which node in the cluster it is currently 
running on. 


7 Click OK to save the MTA description. 


8 Continue with Recording Cluster-Specific Information about the Internet Agent. 


Recording Cluster-Specific Information about the Internet Agent 


With the contents of the Internet Agent domain still displayed: 


1 Right-click the Internet Agent object, then click Properties. 
2 Click GroupWise, then click Identification. 


3 Inthe Description field, record the secondary IP address of the cluster-enabled Internet Agent 
domain volume and the cluster-unique port numbers used by the Internet Agent. 


This information appears on the Internet Agent console, no matter which node in the cluster it is 
currently running on. 


4 Click OK to save the Internet Agent information. 


5 Continue with Knowing What to Expect in an Internet Agent Failover Situation. 


Knowing What to Expect in an Internet Agent Failover Situation 


The failover behavior of the MTA for the Internet Agent domain is the same as for an MTA ina 
regular domain. See “Knowing What to Expect in MTA and POA Failover Situations” on page 59. 


Failover of the Internet Agent itself is more complex. The various clients (POP3, IMAP4, and LDAP) 
receive an error message that the node is not available. Most of the clients do not attempt to reconnect 
automatically, so the user must exit the client and restart it to reestablish the connection after the 
failover process is complete. Fortunately, the Internet Agent restarts quickly in its failover location so 
users can reconnect quickly. 


As with the MTA and the POA, migration of the Internet Agent takes longer than failover. In fact, the 
Internet Agent can seem especially slow to shut down properly as it finishes its normal processing 
and stops its threads. For a busy Internet Agent, you might need to wait several minutes for it to shut 
down properly. 


Internet Agent Clustering Worksheet 


Item Explanation 

1) Shared Volume for Internet Specify the name (cluster_volume) of the shared volume where the 
Agent: Internet Agent domain will be created. 

Cluster Enabled? For cluster-enabling, specify the IP addresses of the virtual server 


(volume_SERVER.cluster) to which the cluster-enabled volume is 
+ Yes (highly recommended) tied. 


Cluster volume IP address For more information, see “Deciding Whether to Cluster-Enable the 


Internet Agent Volume” on page 64. 
+ No 
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Item 


2) Internet Agent 
Domain Name: 


Domain Database Location: 


3) Internet Agent 
Failover Path: 


4) MTA Installation Location: 
+ vol:\system on Internet 
Agent volume 


+ sys:\systemon each 
node 


Consolidate multiple MTA 
startup files on Internet 
Agent volume? 


5) MTA Network Information: 


+ MTA IP address 
+ MTA message transfer port 
+ MTA live remote port 


+ MTA HTTP port 


6) Internet Agent 
Installation Location: 


* vol:\systemon the 
Internet Agent volume 


+ sys:\systemon each 
node 


Consolidate multiple 
Internet Agent configuration 
files on Internet Agent 
volume? 


7) Internet Agent 
Network Information: 


¢ Internet Agent IP address 


+ Internet Agent HTTP port 
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Explanation 


Specify a unique name for the Internet Agent domain. Specify the 
directory on the Internet Agent volume where you want to create the 
new domain. 


For more information, see “Planning a Domain for the Internet Agent” 
on page 64. 


List other nodes in the cluster where the Internet Agent and its MTA 
could fail over. 


For more information, see “Determining an Appropriate Failover Path 
for the Internet Agent Volume” on page 64. 


Mark the location where you will install the MTA software. If 
necessary, specify the location where you will consolidate multiple 
MTA startup files on an Internet Agent volume. 


For more information, see “Deciding Where to Install the Internet 
Agent and Its MTA” on page 66. 


Gather the MTA network address information from the Internet Agent 
section of the “IP Address Worksheet” on page 35. 


For more information, see “Planning a Secondary IP Address and 
Cluster-Unique Port Numbers for the Internet Agent and Its MTA” on 
page 65. 


Mark the location where you will install the Internet Agent software. 


If necessary, specify the location where you will consolidate multiple 
Internet Agent configuration files (gwia . cfg) on an Internet Agent 
volume. 


For more information, see “Deciding Where to Install the Internet 
Agent and Its MTA” on page 66. 


Gather the Internet Agent network address information from the 
Internet Agent section of the “IP Address Worksheet” on page 35. 


For more information, see “Planning a Secondary IP Address and 
Cluster-Unique Port Numbers for the Internet Agent and Its MTA” on 
page 65. 


4.5 


Item Explanation 


8) Load Internet Agent and Its Mark whether you need to run the Internet Agent and its MTA in 
MTA protected memory. If so, specify a unique address space for each 
in Protected Memory? agent. 

+ No For more information, see “Deciding Whether to Run the Internet 


eee Agent and Its MTA in Protected Memory” on page 66. 


Protected address space names: 


* MTA: 


+ Internet Agent: 


Internet Agent Quick Checklist 


O Plan the new clustered Internet Agent, including the new domain required to house the Internet 
Agent in a clustering environment. 
See Section 4.1, “Planning the Internet Agent in a Cluster,” on page 63. 

O Make sure your firewall is configured to accommodate the Internet Agent. 
See Section 4.1.5, “Preparing Your Firewall for the Internet Agent,” on page 65. 

O Cluster-enable the volume where the Internet Agent domain will reside. 


See Section 5.3.1, “Cluster-Enabling a Shared Volume for Use with the WebAccess Agent,” on 
page 85. 


C Create the new Internet Agent domain. 
See Section 4.2.2, “Creating a Domain for the Internet Agent,” on page 68. 
C Set up the MTA for the new Internet Agent domain. 
See Section 4.2.3, “Installing the MTA for the Internet Agent Domain,” on page 68. 
C Install the Internet Agent. 
See “Installing the Internet Agent Software in a Cluster” on page 68. 
O Modify the Internet Agent volume resource load script: 
+ Remove the trustmig command 
+ Add the search add command (optional) 


¢ If you will not run the MTA and the Internet Agent in protected memory, add the set auto 
restart commands and the set developer option = off command 


+ Add the load commands for the MTA and the Internet Agent, separating them with a 
delay command 


¢ If you will run the MTA and the Internet Agent in protected memory, add the address space 
parameter to the load commands and adda protection restart command for the 
address space 


See “Modifying the Volume Resource Load Script for the Internet Agent” on page 69. 
O Modify the Internet Agent volume resource unload script: 
+ Add the MTA and Internet Agent or address space unload command(s) 


+ Remove the trustmig command 
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See “Modifying the Volume Resource Unload Script for the Internet Agent” on page 71. 
C Set up the Internet Agent volume failover path and policies. 

See “Setting the Failover Path and Policies for the Internet Agent” on page 72. 
C Enable Internet Addressing for the clustered Internet Agent. 

See “Enabling Internet Addressing for Your Clustered GroupWise System” on page 73. 
O Double-check the cluster-specific Internet Agent object properties. 

See “Verifying Internet Agent Object Properties” on page 74. 
O Test the clustered Internet Agent. 

See Section 4.2.5, “Testing the Clustered Internet Agent,” on page 75. 


O Record cluster-specific information in the properties pages of the GroupWise objects associated 
with the Internet Agent. 


See Section 4.3.1, “Updating GroupWise Objects with Cluster-Specific Descriptions,” on page 76. 
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5.1 


Implementing WebAccess in a NetWare 
Cluster 


You should already have set up at least a basic GroupWise system, as described in Chapter 2, 
“Planning GroupWise in a NetWare Cluster,” on page 19 and Chapter 3, “Setting Up a Domain and 
Post Office in a NetWare Cluster,” on page 39. As part of this process, the “System Clustering 
Worksheet” on page 33 and the “IP Address Worksheet” on page 35 were filled out. If you do not 
have access to the filled-out worksheets, print the worksheets now and fill in the clustering and 
network address information as it currently exists on your system. You need this information as you 
implement WebAccess in a cluster. 


+ Section 5.1, “Understanding the WebAccess Components,” on page 81 
+ Section 5.2, “Planning WebAccess in a Cluster,” on page 82 

+ Section 5.3, “Setting Up WebAccess in a Cluster,” on page 85 

+ Section 5.4, “Managing WebAccess in a Cluster,” on page 92 

+ Section 5.5, “WebAccess Clustering Worksheet,” on page 94 

+ Section 5.6, “WebAccess Quick Checklist,” on page 95 


Understanding the WebAccess Components 


If you are not familiar with GroupWise WebAccess, review “GroupWise WebAccess Overview” in 
“Installing GroupWise WebAccess” in the GroupWise 8 Installation Guide. 


As you plan WebAccess in a clustering environment, you must keep in mind that WebAccess consists 
of two components: 


+ WebAccess Agent (gwinter.n1m) that will be associated with a GroupWise WebAccess domain 
in the cluster 


+ WebAccess Application (a Java servlet) that will be added to your Web server. You can install the 
WebAccess Application on a clustered Web server or a non-clustered Web server. How to set up 
and manage a clustered Web server is beyond the scope of the GroupWise documentation. If you 
have not clustered your Web server, you can install the WebAccess Application on a server that 
is outside of the cluster where the WebAccess Agent is installed. 
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5.2 


5.2.1 


9.2.2 


Planning WebAccess in a Cluster 


A main system configuration difference between a GroupWise system in a clustering environment 
and a GroupWise system in a regular environment is that you need to create a separate domain to 
house each GroupWise gateway, including the WebAccess Agent. 


Section 5.5, “WebAccess Clustering Worksheet,” on page 94 lists all the information you need as you 
set up the WebAccess Agent in a clustering environment. You should print the worksheet and fill it 
out as you complete the tasks listed below: 

¢ Section 5.2.1, “Planning a New Domain for the WebAccess Agent,” on page 82 

+ Section 5.2.2, “Deciding Whether to Cluster-Enable the WebAccess Agent Volume,” on page 82 


* Section 5.2.3, “Determining an Appropriate Failover Path for the WebAccess Agent Volume,” on 
page 83 

¢ Section 5.2.4, “Planning a Secondary IP Address and Cluster-Unique Port Numbers for the 
WebAccess Agent and Its MTA,” on page 83 


+ Section 5.2.5, “Deciding Where to Install the WebAccess Agent and Its MTA,” on page 83 


¢ Section 5.2.6, “Deciding Whether to Run the WebAccess Agent and Its MTA in Protected 
Memory,” on page 84 


¢ Section 5.2.7, “Planning the MTA Installation,” on page 84 
+ Section 5.2.8, “Planning the WebAccess Installation,” on page 84 


Planning a New Domain for the WebAccess Agent 


The considerations involved in planning a domain for the WebAccess Agent are much the same as 
planning any other domain. In preparation, review “Planning a New Domain”, then print and fill out 
the “Domain Worksheet” in “Domains” in the GroupWise 8 Administration Guide. 


Keep in mind the following cluster-specific details: 


+ When you specify the location for the domain directory on the Domain Worksheet, include the 
shared volume where you want the domain directory to reside. 


+ Do not concern yourself with the GroupWise agent information on the Domain Worksheet. You 
can stop with item 10. You will plan the MTA installation later. 


When you have completed the Domain Worksheet, transfer the key information from the Domain 
Worksheet to the WebAccess Clustering Worksheet. 


WEBACCESS CLUSTERING WORKSHEET 


Under Item 1: Shared Volume for WebAccess Agent, transfer the domain location from the Domain 
Worksheet to the WebAccess Clustering Worksheet. 


Under Item 2: WebAccess Agent Domain Name, transfer the domain name and database directory 
from the Domain Worksheet to the WebAccess Clustering Worksheet. 


Deciding Whether to Cluster-Enable the WebAccess Agent Volume 


You should plan to cluster-enable the shared volume where the WebAccess Agent domain will 
reside. For a review of the benefits of cluster-enabling volumes, see Section 2.6, “Deciding Whether to 
Cluster-Enable the Shared Volumes Used by GroupWise,” on page 23, which describes the issues in 
the context of planning MTA and POA installations. 
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5.2.3 


5.2.4 


5.2.9 


WEBACCESS CLUSTERING WORKSHEET 


Under Item 1: Shared Volume for WebAccess Agent, mark Yes under Cluster Enabled?. 


Cluster-enabling relies on successful short name resolution throughout your system. Review 
Section 2.7, “Ensuring Successful Name Resolution for GroupWise Volumes,” on page 25, which 
describes the issues in the context of planning MTA and POA installations. 


Determining an Appropriate Failover Path for the WebAccess Agent 
Volume 


As with the MTA and the POA, you need to decide which nodes in the cluster are appropriate 
locations where the WebAccess Agent volume could fail over. For a review of failover paths, see 
“Determining Appropriate Failover Paths for the Agents” on page 29, which describes the issues in 
the context of planning MTA and POA installations. 


WEBACCESS CLUSTERING WORKSHEET 


Under Item 4: WebAccess Agent Failover Path, list the nodes that you want to have in the 
WebAccess Agent volume failover path. 


Planning a Secondary IP Address and Cluster-Unique Port Numbers 
for the WebAccess Agent and Its MTA 


As with the MTA and the POA, the WebAccess Agent needs a secondary IP address and cluster- 
unique port numbers. As part of planning to install the MTA and POA, you should already have 
determined the secondary IP address and cluster-unique port numbers for the WebAccess Agent and 
its MTA as you filled out the “IP Address Worksheet” on page 35. If you do not have a filled-out copy 
of this worksheet for your system, print it now and fill in current system information. 


WEBACCESS CLUSTERING WORKSHEET 


Under Item 6: MTA Network Information, transfer the MTA secondary IP address and cluster-unique 
port numbers from the WebAccess section the IP Address Worksheet to the WebAccess Clustering 
Worksheet. 


Under Item 1: Shared Volume for WebAccess Agent, copy the MTA secondary IP address under 
Cluster Volume IP Address as well, because they are the same. 


Under Item 8: WebAccess Agent Network Information, transfer the WebAccess Agent secondary IP 
address (the same as for its MTA) and the cluster-unique WebAccess Agent port number from the 
WebAccess section of the IP Address Worksheet to the WebAccess Clustering Worksheet. 


Deciding Where to Install the WebAccess Agent and Its MTA 


As with the MTA and the POA, you can choose to install the WebAccess Agent and its MTA to the 
sys: \system directory of each node or to a vol: \system directory on the WebAccess Agent volume. 
For a discussion of these alternatives, see “Deciding Where to Install the Agent Software” on page 29, 
which describes the issues in the context of planning MTA and POA installations. If you only have 
one WebAccess Agent for your GroupWise system with several nodes in its failover path, it is an easy 
choice. 
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5.2.6 


5.2.7 


5.2.8 


WEBACCESS CLUSTERING WORKSHEET 


Under Item 5: MTA Installation Location and Item 7: WebAccess Agent Installation Location, mark 
whether you will install the WebAccess Agent and its MTA to sys: \system on each node in the 
cluster or to a vol: \system directory on the WebAccess Agent volume. Also specify where the MTA 
startup file will be stored. 


Deciding Whether to Run the WebAccess Agent and Its MTA in 
Protected Memory 


As with the MTA and the POA, you can choose whether to run the WebAccess Agent in protected 
memory. For a review of the benefits of protected memory, see “Deciding Whether to Run the Agents 
in Protected Memory” on page 31, which describes the issues in the context of planning MTA and 
POA installations. 


You might think that protected memory is not necessary if you have only one WebAccess Agent for 
your GroupWise system because it could never fail over to a node where another WebAccess Agent 
was running. However, because the WebAccess Agent in a cluster is installed into its own domain 
with its own MTA, this MTA could fail over to a node where another MTA was already running. 
Therefore, it is safest to load the WebAccess Agent and its MTA into protected memory. Load each 
agent into its own memory space and mark each memory space as restartable. 


WEBACCESS CLUSTERING WORKSHEET 


Under Item 8: Load WebAccess Agent and Its MTA in Protected Memory?, mark whether you need to 
run the WebAccess Agent and its MTA in protected memory. If you do, provide a protected memory 
address space name for each agent. 


Planning the MTA Installation 
Follow the instructions in “Planning the NetWare Agent Installation” on page 32, then return to this 


point. After you follow the instructions, you will have a filled-out NetWare Agent Worksheet to use 
when you install the MTA. 


IMPORTANT: Do not install the NetWare MTA until you are instructed to do so in Section 5.3, 
“Setting Up WebAccess in a Cluster,” on page 85. 





Planning the WebAccess Installation 


Aside from the cluster-specific issues discussed in the preceding sections, the considerations 
involved in planning to install WebAccess are the same in a clustering environment as for any other 
environment. Review “Planning GroupWise WebAccess”, then print and fill out the “GroupWise 
WebAccess Installation Summary Sheets” in “Installing GroupWise WebAccess” in the GroupWise 8 
Installation Guide. When you set up WebAccess in a cluster, you install the WebAccess Agent and the 
WebAccess Application in two separate steps: 


¢ “Planning the WebAccess Agent Installation” on page 85 
¢ “Planning the WebAccess Application Installation” on page 85 
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IMPORTANT: Do not install the WebAccess software until you are instructed to do so in Section 5.3, 
“Setting Up WebAccess in a Cluster,” on page 85. 





Planning the WebAccess Agent Installation 


For the WebAccess Agent, fill out items 2 through 12 on the GroupWise WebAccess Installation 
Worksheet, taking into account the following cluster-specific issues: 


WEBACCESS INSTALLATION WORKSHEET 


Under Server Information: Installation Path, take into account your decision recorded on the 
WebAccess Clustering Worksheet (Item 7: WebAccess Agent Installation Location). 


Under Server Address, transfer the IP address and port number from the WebAccess Clustering 
Worksheet (Item 8: WebAccess Agent Network Information) filled out in “Planning a Secondary IP 
Address and Cluster-Unique Port Numbers for the WebAccess Agent and Its MTA” on page 83. 


Under Server Address: Configure the WebAccess Agent for Clustering, mark Yes. This causes the 
WebAccess Installation program to customize the WebAccess files for clustering. 


Under Gateway Directory: Domain Directory Path, transfer the domain directory from the Domain 
Worksheet you filled out in “Planning a New Domain for the WebAccess Agent” on page 82. 


Planning the WebAccess Application Installation 


The WebAccess Application can be installed on a clustered or non-clustered Web server. How to set 
up and manage a clustered Web server is beyond the scope of the GroupWise documentation. For 
WebAccess Application planning information, see “Determining the WebAccess and WebPublisher 
Applications’ Configuration” in “Installing GroupWise WebAccess” in the GroupWise 8 Installation 
Guide. 


5.3 Setting Up WebAccess in a Cluster 


You should already have reviewed Section 5.2, “Planning WebAccess in a Cluster,” on page 82 and 
filled out the Section 5.5, “WebAccess Clustering Worksheet,” on page 94. You are now ready to 
complete the following tasks to set up the WebAccess Agent in a clustering environment: 


¢ Section 5.3.1, “Cluster-Enabling a Shared Volume for Use with the WebAccess Agent,” on 
page 85 

¢ Section 5.3.2, “Creating a Domain for the WebAccess Agent,” on page 86 

+ Section 5.3.3, “Installing the MTA for the WebAccess Agent Domain,” on page 86 

+ Section 5.3.4, “Installing and Configuring the WebAccess Agent in a Cluster,” on page 86 

+ Section 5.3.5, “Testing Your Clustered WebAccess Installation,” on page 92 


5.3.1 Cluster-Enabling a Shared Volume for Use with the WebAccess Agent 


1 Complete the cluster-enabling steps in the applicable section of cluster documentation for your 
version of NetWare, as listed in Chapter 1, “Introduction to GroupWise 8 and Novell Cluster 
Services on NetWare,” on page 17. 


The WebAccess Clustering Worksheet provides the volume to cluster-enable, the cluster-enabled 
volume IP address, and the failover path for the WebAccess volume. 
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5.3.2 


5.3.3 


5.3.4 


For a review of the new Novell eDirectory objects that are created when you cluster-enable a 
shared volume, see Section 2.6, “Deciding Whether to Cluster-Enable the Shared Volumes Used 
by GroupWise,” on page 23. 


If you have installed the latest version of ConsoleOne and the Novell Cluster Services snap-in, 
you can rename the cluster-related objects in case your DNS name server cannot resolve object 
names that include the underscore (_) character. 


2 To ensure successful short name resolution, add entries for the WebAccess Agent virtual server 
to support your preferred methods of short name resolution, as described in “Configuring Short 
Name Resolution” on page 40. 


3 Continue with Creating a Domain for the WebAccess Agent. 


Creating a Domain for the WebAccess Agent 


The WebAccess Agent domain will be a secondary domain. To create it, follow the instructions in 
Section 3.3, “Creating a New Secondary Domain in a Cluster,” on page 43, taking your information 
from the WebAccess Clustering Worksheet, rather than the System Clustering Worksheet, then return 
to this point. 


Do not create any post offices in the WebAccess Agent domain. 


Continue with Installing the MTA for the WebAccess Agent Domain. 


Installing the MTA for the WebAccess Agent Domain 


The MTA for the WebAccess Agent domain can be installed just like any other MTA in your clustered 
GroupWise system. Follow the instructions in “Installing the Agent Software in a Cluster” on 
page 46, then return to this point. 


You do not need to edit the MTA startup file. You do not need to modify the Volume Resource 
properties until after you have installed the WebAccess Agent. 


Continue with Installing and Configuring the WebAccess Agent in a Cluster. 


Installing and Configuring the WebAccess Agent in a Cluster 


After you have created a domain for the WebAccess Agent and installed the MTA for that domain, 
you are ready to install and configure the WebAccess Agent. 
+ “Installing the WebAccess Agent Software in a Cluster” on page 86 


+ “Configuring the WebAccess Agent Volume Resource to Load and Unload the WebAccess Agent 
and Its MTA” on page 87 


Installing the WebAccess Agent Software in a Cluster 


The WebAccess Agent is the component of your WebAccess installation that accesses post offices and 
libraries to retrieve information for WebAccess client users. 


1 Map a drive to the WebAccess Agent volume (WebAccess Clustering Worksheet item 1) where 
the WebAccess domain is located. 


The WebAccess Agent volume name will be cluster_volume. For assistance with mapping a drive 
to a cluster-enabled volume, see “Configuring Short Name Resolution” on page 40. 
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2 If you selected vol: \systemon WebAccess Agent volume as the WebAccess Agent installation 
location (WebAccess Clustering Worksheet item 7), create the vol: \system directory on the 
WebAccess Agent volume accessed in Step 1. 


or 


if you selected sys: \system on each node, decide which node you will install the WebAccess 
agent to first, then map a drive to its sys: \system directory. 


3 Start the WebAccess Installation program and install the NetWare WebAccess Agent, following 
Step 1 through Step 5 provided in “Installing the WebAccess Agent” in “Installing GroupWise 
WebAccess” in the GroupWise 8 Installation Guide. Keep in mind the following cluster-specific 
details: 


+ In the Components dialog box, select only GroupWise WebAccess Agent. 
Do not install the WebAccess Application at this time. 


+ Use items 2 through 12 on the GroupWise WebAccess Installation Worksheet that you filled 
out in “Planning the WebAccess Installation” on page 84 to fill in the fields during the 
WebAccess Agent installation process. 


+ In the Network Address dialog box, select Configure GroupWise Agents for Clustering. 


¢ In the Installation Path dialog box, be sure to browse through the drive you mapped to the 
location you chose in Step 2 above. 


¢ Inthe Gateway Directory dialog box, be sure to browse to the domain directory through the 
drive you mapped in Step 1 above. 


+ In the Start Applications dialog box, deselect Start the GroupWise WebAccess Agent. 


+ The WebAccess Installation program creates the strtweb.ncf and stopweb.ncf files, 
which include the load and unload commands for the WebAccess Agent. You use this 
information later when you create the load and unload scripts for the WebAccess Volume 
Resource object. 


4 If you need to install the WebAccess Agent to sys: \system on multiple nodes in the cluster, 
repeat Step 4, mapping new drives as needed. 


5 Make sure you have completed all the WebAccess Agent tasks described in “NetWare and 
Windows: Setting Up GroupWise WebAccess” in “Installing GroupWise WebAccess” in the 
GroupWise 8 Installation Guide, but do not start the WebAccess Agent at this time. 


6 Continue with Configuring the WebAccess Agent Volume Resource to Load and Unload the 
WebAccess Agent and Its MTA. 


Configuring the WebAccess Agent Volume Resource to Load and Unload the 
WebAccess Agent and Its MTA 


The properties of the Volume Resource object define how the WebAccess Agent volume functions 
within the cluster, how NLM programs are loaded and unloaded, and how failover and failback 
situations are handled. Complete the following tasks for the WebAccess Agent volume: 


e “Modifying the Volume Resource Load Script for the WebAccess Agent” on page 87 

e “Modifying the Volume Resource Unload Script for the WebAccess Agent” on page 89 

¢ “Setting the Failover Path and Policies for the WebAccess Agent” on page 91 

¢ “Installing and Configuring the WebAccess Application in a Cluster” on page 92 
Modifying the Volume Resource Load Script for the WebAccess Agent 


The volume resource load script executes whenever the WebAccess Agent volume comes online. 
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To set up the load script: 


1 In ConsoleOne, browse to and select the Cluster object. 
If necessary, click View > Console View to display its contents. 


2 Right-click the Volume Resource object (volume_SERVER), then click Properties > Load to display 
the default volume resource load script for the WebAccess Agent volume. 


The next step assumes that this is the first time you have edited the load script. If other 
GroupWise agents are already running from this volume, some of the modifications have 
already been made. 


3 Make the following changes to the default load script: 


+ Remove the trustmig command. It is not necessary to migrate trustees for the WebAccess 
Agent volume. Removing this line helps the load script to execute faster. 


+ If you selected vol:\system on WebAccess Agent volume as the installation location 
(WebAccess Clustering Worksheet items 5 and 7), add a search add command to add the 
new vol:\system directory to the server search path. 


search add volume:\system 


+ If you selected sys:\system on each node as the installation location (WebAccess 
Clustering Worksheet items 5 and 7) but you are storing the MTA startup file on the 
WebAccess Agent volume, add that location to the server search path. 


+ If you marked No under Load WebAccess Agent and Its MTA in Protected Memory? 
(WebAccess Clustering Worksheet item 9), add the following abend recovery options: 


set auto restart after abend = 2 

set auto restart after abend delay time = 0 
set auto restart down timeout = 60 

set developer option = off 


These settings provide the best possible handling of GroupWise databases in the event that 
an abend should occur within the cluster. 


+ Transfer the MTA load command from the grpwise.ncf file located in the vol:\system 
directory into the load script. Use Ctrl+C and Ctrl+V to copy and paste text into the load 
script page. Then delete or rename the grpwise.ncf file to avoid future confusion. 


load volume:\system\gwmta.nlm @domain.mta 
+ Add a delay so that the MTA is fully loaded before the WebAccess Agent starts to load: 


load delay 
delay 10 


The length of the delay varies from system to system; ten seconds is a good starting place. 


¢ Transfer the WebAccess Agent load command from the strtweb .ncf file located in the 
vol:\system directory into the load script. Use Ctrl+C and Ctrl+V to copy and paste text 
into the load script page. 


load volume:\system\gwinter.nlm 


/ph=volume: \domain\wpgate\webac80a 
/user=username / PASSWORD=password 
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¢ If you marked Yes under Load WebAccess Agent and Its MTA in Protected Memory? 
(WebAccess Clustering Worksheet item 9), add the address space parameter to the load 
commands to specify the protected address space where the WebAccess Agent and its MTA 
will run. Add a protection restart command for the address space name. 


load address space=addr_space_name 
volume: \system\gwmta.nlm @domain.mta 

load address space=addr_space_name 
volume: \system\gwinter.nlm 
/ph=volume: \domain\wpgate\webac80a 
/user=username /password=password 

protection restart addr_space_name 


The result would look similar to the following example: 


Properties of GWVOL_SERVER |x} 
IP Address | Load Unload | Policies | Nodes | NDS Rights ~ | Other | Rights to Files and Fold 


| Cluster Resource Load Script | 


Script 





nss /activate=GVWVOL a 
mount GWWVOL VOLID=254 

cyshind add GVW-CLUSTER_GWVOL_SERVER 123.45.67.18 # NetWare 5.1 only 

NUDP ADD GWV-CLUSTER_GWVOL_SERVER 123.45.67.18 

add secondary ipaddress 123.45.67.18 

search add gwvolsystem 


SET AUTO RESTART AFTER ABEND = 2 

SET AUTO RESTART AFTER ABEND DELAY TIME = 0 
SET AUTO RESTART DOWN TIMEOUT = 60 

SET DEVELOPER OPTION = OFF 


LOAD address space=webacc GYVOLASYSTEMIGWWMTA @PROVO1.MTA 

LOAD DELAY, DELAY 10 

LOAD address space=webacc GYVVOLASYSTEMIGWINTER /PH=GWVVOLAPROVO 1WY¥PGATEWYEBACBOA 
protection restart webace 


Kil > 
Timeout (secs) |600 











Page Options... | OK | Cancel | spay] Help | 





NOTE: The set commands are needed only when the MTA and the WebAccess Agent are not 
running in protected memory. The address space parameters are needed in the load commands 
only when the MTA and the WebAccess Agent are running in protected memory. 





For another example of a load script, see TID 7006193: Running the GroupWise Agents in a Non- 
Protected Address Space on a NetWare Cluster in the Novell Knowledgebase (http:// 
www.novell.com/support). 


4 Click Apply to save the load script. 


5 If necessary, click OK to confirm that you must offline and then online the volume resource in 
order for the changes to take effect. 


6 Continue with Modifying the Volume Resource Unload Script for the WebAccess Agent. 


Modifying the Volume Resource Unload Script for the WebAccess Agent 


The volume resource unload script executes whenever the WebAccess Agent volume goes offline. 
Programs should be unloaded in the reverse order of how they were loaded. This ensures that 
supporting programs are not unloaded before programs that rely on them in order to function 


properly. 
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To set up the unload script: 


1 In ConsoleOne, in the properties pages for the Volume Resource object (volume_SERVER), click 
Unload to display the default volume resource unload script. 


The next step assumes that this is the first time you have edited the unload script. If other 
GroupWise agents are already running from this volume, some of the modifications have 
already been made. 


2 Make the following changes to the default unload script: 


¢ If you marked Yes under Load WebAccess Agent and Its MTA in Protected Memory? 
(WebAccess Clustering Worksheet item 9), add an unload address space command and 
an unload kill address space command to ensure that the address space is completely 
cleaned up. 


unload address space=addr_space_name 
unload kill address space=addr_space_name 


If your system seems to be trying to kill the address space before the WebAccess Agent and 
its MTA have been completely unloaded, resulting in the agents hanging in the unloading 
state, set a delay of several seconds before issuing the unload kill address space 
command to allow the WebAccess Agent and its MTA adequate time to unload completely. 
The length of the delay varies from system to system; ten seconds is a good starting place. 


unload address space=addr_space_name 
delay 10 
unload kill address space=addr_space_name 


¢ If you marked No under Load WebAccess Agent and Its MTA in Protected Memory? 
(WebAccess Clustering Worksheet items 9), create an unload command parallel to each 
load command that you placed in the load script. 


unload gwinter.nlm 
unload gwmta.nlm 


+ Remove the trustmig command just like you did in the load script. 


The result would look similar to the following example: 


Properties of GWVOL_SERVER |x| 


IP Address | Load |{i Policies | Nodes | NDS Rights ~ | Other | Rights to Files and Fold 





Script 





unload address space = webacc a 


del secondary ipaddress 123.45.67.18 

NUDP DEL GW-CLUSTER_GWWOL_SERVER 123.45.67.18 

cvysbind del GW-CLUSTER_GWVOL_SERYER 123.45.67.18 # NetWare 5.1 only 
dismount GWVOL force 

nss forcedeactivate=GWVOL 





4 > 
Timeout (secs) [600 








Page Options... | OK | Cancel | Apnty Help | 


3 Click Apply to save the unload script. 


4 If necessary, click OK to confirm that you must offline and then online the volume resource in 
order for the changes to take effect. 


5 Continue with Setting the Failover Path and Policies for the WebAccess Agent. 
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Setting the Failover Path and Policies for the WebAccess Agent 
To modify the failover path and policies for the WebAccess Agent volume resource: 


1 In ConsoleOne, in the properties pages for the Volume Resource object (volume_SERVER), click 
Nodes to display the default failover path for the WebAccess Agent volume resource. 





i Properties of GWVOL_SERVER 


IP Address | Load | Unload | Poicies | 


GW-CLUSTER1 
GW-CLUSTER2 


É GW-CLUSTER4 














2 Arrange the nodes in the cluster into the desired failover path for the WebAccess Agent volume 
(WebAccess Clustering Worksheet item 4). 


3 Click Apply to save the failover path. 
4 Click Policies to display the default start, failover, and failback policies. 





i Properties of GWVOL_SERVER 





The default policy settings are often appropriate. By default, a volume resource: 
¢ Fails over automatically if the node it is running on fails 
¢ Starts automatically on the next node in its failover path 


¢ Continues running at its failover location, even after its most preferred node is again 
available 


If you are considering changing these defaults, see the section about failover and failback mode 
modes in the clustering documentation for your version of NetWare, as listed in Chapter 1, 
“Introduction to GroupWise 8 and Novell Cluster Services on NetWare,” on page 17. 


5 Click OK when you are finished editing the WebAccess Agent volume resource properties. 


6 Continue with “Installing and Configuring the WebAccess Agent in a Cluster” on page 86. 
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5.3.5 


5.4 


5.4.1 


Installing and Configuring the WebAccess Application in a Cluster 


If you have clustered your Web server, you must install the WebAccess Application on each node 
where the Web server is installed, as described in “Installing the WebAccess Application and 
WebPublisher Application” in “Installing GroupWise WebAccess” in the GroupWise 8 Installation 
Guide. 


Testing Your Clustered WebAccess Installation 


Remember that the WebAccess Agent volume resource and the WebAccess Application on your Web 
server are separate and could fail over to different nodes at different times. 


To thoroughly test your WebAccess installation: 
1 Make sure the initial combination of WebAccess Agent volume resource and the WebAccess 
Application installed on your Web server is functioning properly. 


2 Migrate the WebAccess Agent volume resource to each node on its failover path, making sure it 
functions with your Web server. 


3 If your Web server is clustered, migrate the Web server cluster resource to a different node, 
migrate the WebAccess Agent volume resource to each node in the Web server cluster resource 
failover path, then make sure each combination works. 


4 Repeat Step 3 for each Web server cluster resource. 


Managing WebAccess in a Cluster 


After you have installed WebAccess in a cluster, you should consider some long-term management 
issues. 


+ Section 5.4.1, “Updating GroupWise Objects with Cluster-Specific Descriptions,” on page 92 
+ Section 5.4.2, “Knowing What to Expect in WebAccess Failover Situations,” on page 93 
+ Section 5.4.3, “Updating the WebAccess Agent Configuration File (commegr.cfg),” on page 94 


Updating GroupWise Objects with Cluster-Specific Descriptions 


After installing WebAccess in your clustered GroupWise system, while the cluster-specific 
information is fresh in your mind, you should record that cluster-specific information as part of the 
GroupWise objects in ConsoleOne so that you can easily refer to it later. Be sure to update the 
information recorded in the GroupWise objects if the configuration of your system changes. 


e “Recording Cluster-Specific Information about the WebAccess Agent Domain and Its MTA” on 
page 92 
¢ “Recording Cluster-Specific Information about the WebAccess Agent” on page 93 


Recording Cluster-Specific Information about the WebAccess Agent Domain and 
Its MTA 


To permanently record important cluster-specific information for the WebAccess Agent domain: 


1 In ConsoleOne, browse to and right-click the Domain object, then click Properties. 
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2 Inthe Description field of the WebAccess Agent domain Identification page, provide a cluster- 
specific description of the WebAccess Agent domain, including the secondary IP address of its 
cluster-enabled volume and the cluster-unique port numbers used by its MTA. 


You might also want to include cluster-specific information about the WebAccess Application, 
such as the secondary IP address of the Web server cluster resource where the WebAccess 
Application is installed. 


Click OK to save the WebAccess Agent domain description. 
Select the WebAccess Agent Domain object to display its contents. 
Right-click the MTA object, then click Properties. 


In the Description field of the MTA Identification page, record the secondary IP address of the 
cluster-enabled WebAccess Agent domain volume and the cluster-unique port numbers used by 
the MTA. 


This information appears on the MTA console, no matter which node in the cluster it is currently 
running on. 


7 Click OK to save the MTA description. 


8 Continue with Recording Cluster-Specific Information about the Internet Agent. 


oa fF Ww 


Recording Cluster-Specific Information about the WebAccess Agent 


With the contents of the WebAccess Agent domain still displayed: 


1 Right-click the WEBAC80A object, then click Properties. 
2 Click GroupWise, then click Identification. 


3 In the Description field, record the secondary IP address of the cluster-enabled WebAccess Agent 
domain volume and the cluster-unique port numbers used by the WebAccess Agent. 


This information appears on the WebAccess Agent console, no matter which node in the cluster 
it is currently running on. 


4 Click OK to save the WebAccess Agent information. 
5 Continue with Knowing What to Expect in MTA and POA Failover Situations. 


Knowing What to Expect in WebAccess Failover Situations 


The failover behavior of the MTA for the WebAccess Agent domain is the same as for an MTA ina 
regular domain. See “Knowing What to Expect in MTA and POA Failover Situations” on page 59. 


The WebAccess Application caches users’ credentials on the node where it is running. Therefore, if 
that node fails, or if the WebAccess Application migrates to a different node, the cached credentials 
are lost. Consequently, the user needs to restart the WebAccess client in order to re-authenticate and 
re-establish the credentials. 


If the WebAccess Agent fails over or migrates, the user receives an error message that the WebAccess 
Agent is no longer available. However, after the WebAccess Agent starts in its new location, the 
WebAccess Application passes the cached user credentials to the WebAccess Agent and the user 
reconnects automatically without having to re-authenticate. 


As with the MTA and the POA, migration of the WebAccess Agent takes longer than failover. 
However, the WebAccess Agent restarts quickly so that users are able to reconnect quickly. 
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Updating the WebAccess Agent Configuration File (commgr.cfg) 


As part of installing WebAccess, the WebAccess Agent configuration file (commgr . cfg) is created in 
the following subdirectory: 


domain\wpgate\webac80a 
It is also automatically copied to the following Web server subdirectory: 
sys: \novell\webaccess 


If you change WebAccess agent configuration information (for example, if you change its ip address), 
the information is changed in the following file: 


domain\wpgate\webac80a\commgr.cfg 
because the domain is on a cluster-enabled volume, and it is changed in the following file: 
sys: \novell\webaccess\commgr.cfg 


on the node where the WebAccess Application is currently running. However, the other nodes on the 
WebAccess Application failover path are not currently available for update. therefore, you must 
manually copy the updated commgr . cfg file to the sys: \novell\webaccess subdirectory on each 
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node in the WebAccess Application failover path. 


WebAccess Clustering Worksheet 


Item 


1) Shared Volume for 
WebAccess Agent: 


Cluster Enabled? 
+ Yes (highly recommended) 


Cluster volume IP address 


+ No 


2) WebAccess Agent 
Domain Name: 


Domain Database Location: 


3) WebAccess Agent 
Failover Path: 
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Explanation 


Specify the name (cluster_volume) of the shared volume where the 
WebAccess Agent domain will be created. 


For cluster-enabling, specify the IP addresses of the virtual server 
(volume _.cluster) to which the cluster-enabled volume is tied. 


For more information, see “Deciding Whether to Cluster-Enable the 
WebAccess Agent Volume” on page 82. 


Specify a unique name for the WebAccess Agent domain. Specify the 
directory on the WebAccess Agent volume where you want to create 
the new domain. 


For more information, see “Planning a New Domain for the 
WebAccess Agent” on page 82. 


List other nodes in the cluster where the WebAccess Agent and its 
MTA could fail over. 


For more information, see “Determining an Appropriate Failover Path 
for the WebAccess Agent Volume” on page 83. 


5.6 


Item 
4) MTA Installation Location: 
¢ vol:\systemon 
WebAccess Agent volume 


+ sys:\systemon each 
node 


Consolidate multiple MTA 
startup files on WebAccess 
Agent volume? 


5) MTA Network Information: 


+ MTA IP address 
+ MTA message transfer port 
+ MTA live remote port 


+ MTA HTTP port 


6) WebAccess Agent 
Installation Location: 


+ vol:\system on the 
WebAccess Agent volume 


¢ sys:\system on each 
node 


7) WebAccess Agent 
Network Information: 


+ WebAccess Agent IP 
address 


+ WebAccess Agent HTTP 
port 


8) Load WebAccess Agent and 
Its MTA in Protected Memory? 


+ No 
+ Yes 


Protected address space names: 


* MTA: 


+ WebAccess: 


Explanation 


Mark the location where you will install the MTA software. 


If necessary, specify the location where you will consolidate multiple 
MTA startup files on a WebAccess Agent volume. 


For more information, see “Deciding Where to Install the WebAccess 
Agent and Its MTA” on page 83. 


Gather the MTA network address information from the WebAccess 
section of the “IP Address Worksheet” on page 35. 


For more information, see “Planning a Secondary IP Address and 
Cluster-Unique Port Numbers for the WebAccess Agent and Its MTA” 
on page 83. 


Mark the location where you will install the WebAccess Agent 
software. 


For more information, see “Deciding Where to Install the WebAccess 
Agent and Its MTA” on page 83. 


Gather the WebAccess Agent network address information from the 
WebAccess section of the “IP Address Worksheet” on page 35. 


For more information, see “Planning a Secondary IP Address and 
Cluster-Unique Port Numbers for the WebAccess Agent and Its MTA” 
on page 83. 


Mark whether you need to run the WebAccess Agent and its MTA in 
protected memory. If so, specify a unique address space for each 
agent. 


For more information, see “Deciding Whether to Run the WebAccess 
Agent and Its MTA in Protected Memory” on page 84. 


WebAccess Quick Checklist 


O Plan the new clustered WebAccess installation, including the new domain required to house the 
WebAccess Agent in a clustering environment. 


See Section 5.2, “Planning WebAccess in a Cluster,” on page 82. 


© Cluster-enable the volume where the WebAccess Agent domain will reside. 
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See Section 5.3.1, “Cluster-Enabling a Shared Volume for Use with the WebAccess Agent,” on 
page 85. 


Create the new WebAccess Agent domain. 
See Section 5.3.2, “Creating a Domain for the WebAccess Agent,” on page 86. 
Set up the MTA for the new WebAccess Agent domain. 
See Section 5.3.3, “Installing the MTA for the WebAccess Agent Domain,” on page 86. 
Install the WebAccess Agent. 
See Section 5.3.4, “Installing and Configuring the WebAccess Agent in a Cluster,” on page 86. 
Modify the WebAccess Agent volume resource load script: 
+ Remove the trustmig command 
+ Add the search add command (optional) 


¢ If you will not run the MTA and the WebAccess Agent in protected memory, add the set 
auto restart commands and the set developer option = off command 


+ Add the load commands for the MTA and the WebAccess Agent, separating them with a 
delay command 


¢ If you will run the MTA and the WebAccess Agent in protected memory, add the address 
space parameter to the load commands and add a protection restart command for the 
address space 


See “Modifying the Volume Resource Load Script for the WebAccess Agent” on page 87. 
Modify the WebAccess Agent volume resource unload script: 
+ Add the MTA and WebAccess Agent or address space unload command(s) 
+ Remove the trustmig command 
See “Modifying the Volume Resource Unload Script for the WebAccess Agent” on page 89. 
Set up the WebAccess Agent volume failover path and policies. 
See “Setting the Failover Path and Policies for the WebAccess Agent” on page 91. 
Test the clustered WebAccess Agent. 
See Section 5.3.5, “Testing Your Clustered WebAccess Installation,” on page 92. 


Record cluster-specific information in the properties pages of the GroupWise objects associated 
with the WebAccess Agent. 


See Section 5.4.1, “Updating GroupWise Objects with Cluster-Specific Descriptions,” on page 92. 
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Implementing GroupWise Gateways ina 
NetWare Cluster 


A significant system configuration difference between a GroupWise system in a clustering 
environment and a GroupWise system in a regular environment is that you need to create a separate 
domain to house each GroupWise gateway. The gateway domain should be created on a cluster- 
enabled volume. This enables the gateway to fail over independently from other GroupWise 
components. 


If you have set up the Internet Agent or WebAccess in your clustered GroupWise system, you should 
already have the skills necessary to set up a GroupWise gateway as well. 


GroupWise gateways that have not received recent development have not been thoroughly tested in 
a clustering environment. If you are currently using such GroupWise gateways, you might want to 
leave them outside of your cluster. 
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Monitoring a GroupWise System ina 
NetWare Cluster 


Because the GroupWise 8 Monitor currently runs on Windows and Linux, rather than NetWare, you 
cannot run GroupWise Monitor in a NetWare cluster. However, GroupWise Monitor can easily 
monitor a clustered GroupWise system from a vantage point outside the NetWare cluster. 


When you first install Monitor, it gathers information about agents to monitor from a domain 
database (wpdomain.db). This provides the secondary IP address of each agent (the IP address 
associated with the cluster-enabled volume where the agent’s domain or post office resides). When an 
agent fails over or migrates to a different node, its status in Monitor displays as Not Listening until it 
is up and running again, at which time its status returns to Normal. 


Because Monitor must use secondary IP addresses to monitor the agents in a clustered GroupWise 
system, the Discover Machine and Discover Network options do not work in a cluster. Secondary IP 
addresses cannot be obtained by examining the network itself. If you need to add agents to monitor, 
use the Add Agent option and provide the agent’s secondary IP address. 


For instructions on setting up GroupWise Monitor, see “Installing GroupWise Monitor” in the 
GroupWise 8 Installation Guide. 
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Backing Up a GroupWise System ina 
NetWare Cluster 


The GroupWise Target Service Agent for File Systems (TSAFSGW) is a GroupWise-specific API that 
works with compatible backup software to provide reliable backups of a running GroupWise system 
on NetWare 6.5. TSAFSGW can be used in a clustered GroupWise system with appropriate 
preparation and understanding of how the TSAs work. For background information about the 
GroupWise TSAs, see “GroupWise Target Service Agent” in “Databases” in the GroupWise 8 
Administration Guide. 


In a clustering environment, TSAFSGW must be installed and loaded on each node from which your 
backup software backs up any portion of your GroupWise system. To accommodate the variable 
locations of data to back up from a clustered GroupWise system, the .ncf file for TSAFSGW on each 
node should be edited to include a /home startup switch for every domain and post office on every 
shared volume that might ever be mounted on that node. 


If you are using TSAFSGW, the /vserver switch enables you to specify the name of a virtual server in 
your NetWare cluster. Then you can use the /home switch to specify shared volumes and paths rather 
than physical volumes and paths. For example: 


/vserver-clustername_volumename_SERVER 
/home-volumename:\domain_directory 
/home-volumename:\post_office directory 


For example, if you have a domain named NewYork and a post office named Engineering, with 
libraries named Design and Training, the switches for TSAFSGW would be: 


/vserver-CORPORATE GROUPWISE SERVER 
/home-gw: \gwsystem\newyork 
/home-gw: \gwsystem\engineering 


You can use this same configuration file on every node in the cluster. TSAFSGW can identify the 
libraries based on information provided by the post office. Your backup software would then list the 
following locations to back up, based on the previous example: 


GroupWise Cluster System 
[DOM] newyork 

[PO] engineering 

[DMS] 11ib0001 

[BLB] design store 

[DMS] 11ib0002 

[BLB] training store 








From the list provided in your backup software, you can select GroupWise Cluster System to back up 
all the objects listed, or you can select individual objects for backup. 


When TSAFSGW runs, it backs up the shared volumes that are currently accessible and skips shared 
volumes that are not currently accessible. If a shared volume migrates, you must restart TSAFSGW so 
that it can re-determine what shared volumes are currently available for backup. 
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TSAFSGW connects to the virtual server from all nodes in the cluster. If the node where TSAFSGW is 
performing a backup goes down, that node is dismounted and the next node is mounted to the 
virtual server. TSAFSGW on the next node is aware of this and notifies your backup software. Your 
backup software acknowledges the disruption and attempts to reconnect to the next node. When the 
next node is fully up and responding, the backup recommences, starting with the resource that was 
being backed up when the disruption occurred. 


To restore data in a clustering environment, you must run your backup/restore software on the node 
where the location to restore is currently mounted. 
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Updating a GroupWise System ina 
NetWare Cluster 


In a NetWare cluster, you have the option of installing the GroupWise software on each node in the 
cluster or on a GroupWise volume along with a domain or post office, as described in Section 2.8.3, 
“Deciding Where to Install the Agent Software,” on page 29. Before you run the GroupWise 
Installation program to install updated software, make sure you understand where in your cluster 
the GroupWise software is already installed. 


If your existing GroupWise software is installed on each cluster node, it is very important to update 

all nodes on the failover path of each domain and post office at once, because each domain and post 
office should be serviced by only one version of the agent software. If you do not update all nodes on 
the failover path at once, there is the potential for a domain or post office to be serviced by a different 
version of the agent software during a failover situation. This can cause database problems. 


If your existing GroupWise software is installed on a GroupWise volume along with a domain or 
post office, updating the agent software on the GroupWise volume needs to be done only once, 
because the agents fail over along with the domain or post office they service. 


Keep in mind these cluster-specific details as you follow the instructions in “Update” in the 
GroupWise 8 Installation Guide to update your GroupWise system in a NetWare cluster. 
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Moving an Existing GroupWise 8 System 
into a NetWare Cluster 


If you are adding the high availability benefits of Novell Cluster Services to a GroupWise 8 system 
that is already up and running, the first step is to install Novell Cluster Services following the 
instructions in the clustering documentation for your version of NetWare, as listed in Chapter 1, 
“Introduction to GroupWise 8 and Novell Cluster Services on NetWare,” on page 17. You should also 
review Chapter 1, “Introduction to GroupWise 8 and Novell Cluster Services on NetWare,” on 

page 17 to help you apply clustering principles and practices to your GroupWise system. 


You do not need to transfer your entire GroupWise system into the cluster all at once. You could 
transfer individual post offices where the needs for high availability are greatest. You could transfer a 
domain and all of its post offices at the same time. You might decide that you don’t need to have all of 
your GroupWise system running in the cluster. 


This section provides a checklist to help you get started with moving your GroupWise system into a 
clustering environment: 


O Decide which shared volumes in your shared disk system you will use for GroupWise 
administration (ConsoleOne and the software distribution directory). 


O Decide which shared volumes in your shared disk system you will use for GroupWise domains 
and post offices. 


O Decide which nodes in your storage area network you will have on failover paths for the 
GroupWise agents. 


O Review Chapter 2, “Planning GroupWise in a NetWare Cluster,” on page 19. Fill out the “System 
Clustering Worksheet” on page 33 to help you decide which domains and post offices you will 
move to which shared volumes. 


O Review “Planning Secondary IP Addresses and Cluster-Unique Port Numbers for Agents in the 
Cluster” on page 27 and fill out the “IP Address Worksheet” on page 35 to select secondary IP 
addresses for cluster-enabled volumes and to specify cluster-specific port numbers for all of 
your GroupWise agents. 


O Select the first shared volume that will be part of your clustered GroupWise system and cluster- 
enable it, following the instructions in “Cluster-Enabling Shared Volumes for Use with 
GroupWise” on page 39 and “Configuring Short Name Resolution” on page 40. 


O Move a domain and/or post office onto the cluster-enabled volume, following the instructions in 
“Moving a Domain” in “Domains” or “Moving a Post Office” in “Post Offices” in the GroupWise 
8 Administration Guide. 


O Review Section 2.8, “Deciding How to Install and Configure the Agents in a Cluster,” on 
page 26, fill out the “Agent Clustering Worksheet” on page 36, and install the agents as needed 
for the first clustered domain and/or post office, following the instructions in Section 3.5, 
“Installing and Configuring the MTA and the POA in a Cluster,” on page 46. This includes 
setting up the load and unload scripts for the cluster-enabled volume. 
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C Test the first component of your clustered GroupWise system following the instructions in 
Section 3.6, “Testing Your Clustered GroupWise System,” on page 54. 


O Take care of the cluster management details described in Section 3.7, “Managing Your Clustered 
GroupWise System,” on page 55. 


O Move more domains and post offices into the cluster as needed. If you have GroupWise libraries, 
see Section 2.5, “Planning a New Library for a Clustered Post Office,” on page 23. 


O Move GroupWise administration into the cluster as needed. 


O Add other components to your clustered GroupWise system as needed, following the 
instructions in: 


¢ Chapter 4, “Implementing the Internet Agent in a NetWare Cluster,” on page 63 

+ Chapter 5, “Implementing WebAccess in a NetWare Cluster,” on page 81. 

+ Chapter 6, “Implementing GroupWise Gateways in a NetWare Cluster,” on page 97 
+ Chapter 7, “Monitoring a GroupWise System in a NetWare Cluster,” on page 99 

¢ Chapter 8, “Backing Up a GroupWise System in a NetWare Cluster,” on page 101 
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Implementing Messenger in a NetWare 
Cluster 


Novell Messenger does not require the existence of a GroupWise system in the cluster, but 
presumably one has already been set up as described in Chapter 2, “Planning GroupWise in a 
NetWare Cluster,” on page 19 and Chapter 3, “Setting Up a Domain and Post Office in a NetWare 
Cluster,” on page 39. As part of the process of setting up GroupWise in the cluster, you filled out the 
“System Clustering Worksheet” on page 33. Some of the information from that worksheet is helpful 
as you implement Messenger in your cluster. 


¢ Section 11.1, “Planning Your Messenger System in a Cluster,” on page 107 


è Section 11.2, “Setting Up Your Messenger System in a Cluster,” on page 110 
+ Section 11.3, “Messenger Clustering Worksheet,” on page 115 


11.1 Planning Your Messenger System in a Cluster 


Because the Messenger agents are not associated with GroupWise domains or post offices, the 
Messenger agents are easier to implement in a cluster than are the GroupWise agents. Section 11.3, 
“Messenger Clustering Worksheet,” on page 115 lists all the information you need as you set up the 
Messenger agents in a clustering environment. You should print the worksheet and fill it out as you 
complete the tasks listed below: 


+ “Understanding Your Cluster” on page 107 

¢ “Planning Messenger Administration” on page 107 

¢ “Deciding Where to Install the Messenger Agent Software” on page 108 
¢ “Planning the Messenger Agent Installation” on page 109 


11.1.1 Understanding Your Cluster 


Fill out items 1 through 5 on the Section 11.3, “Messenger Clustering Worksheet,” on page 115 with 
information about your cluster. This information corresponds to items 1-5 on the “System Clustering 
Worksheet” on page 33. For background information, see Section 2.1, “Meeting Software Version 
Requirements,” on page 20 and Section 2.2, “Installing Novell Cluster Services,” on page 20. 


11.1.2 Planning Messenger Administration 


If you have set up a cluster-enabled shared volume for GroupWise administration, as described in 
Section 2.6, “Deciding Whether to Cluster-Enable the Shared Volumes Used by GroupWise,” on 
page 23, you can use the same cluster-enabled shared volume for the Messenger administration files. 
For example, you might have a shared pub: volume with a \public directory where you install the 
Messenger snap-in to ConsoleOne. Or you can install the Messenger snap-in on one or more 
administrator workstations. 
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MESSENGER CLUSTERING WORKSHEET 


Under Item 6: Installation Location for Messenger Administration, mark where you want to install the 
Messenger snap-in to ConsoleOne. 


If you plan to install the Messenger snap-in to ConsoleOne on a cluster-enabled shared volume, 
under Item 7: Shared Volume for Messenger Administration, list the IP address of the shared volume 
and the directory where you want to install the Messenger snap-in. 


IMPORTANT: Cluster-enabling relies on successful short name resolution throughout your system. 
Review Section 2.7, “Ensuring Successful Name Resolution for GroupWise Volumes,” on page 25, 
which describes the issues in the context of planning MTA and POA installations for GroupWise. 


Deciding Where to Install the Messenger Agent Software 


When you install the NetWare Messenger agents in a clustering environment, you can choose 
between two different installation locations: 


Table 11-1 Messenger Agent Software Installation Locations 


Location Description 

Each node The sys: \system directory is the default location provided by the Messenger 
in the cluster Installation program. 

Shared volume If you create a vol: \system directory on a cluster-enabled shared volume, 


the agent software and startup files fail over and back along with supporting 
files such as the Messenger archive. 


IMPORTANT: Cluster-enabling relies on successful short name resolution 
throughout your system. Review Section 2.7, “Ensuring Successful Name 
Resolution for GroupWise Volumes,” on page 25, which describes the issues in 
the context of planning MTA and POA installations for GroupWise. 


You must install to a cluster-enabled shared volume if you do not want a separate Messenger archive 
to be created on each node where the Archive Agent runs. If you do not want to use a shared volume, 
you should plan to install the Archive Agent separately outside the cluster. 

MESSENGER CLUSTERING WORKSHEET 


Under Item 8: Installation Location for Messenger Agents, mark where you want to install the 
Messenger agent software. 


Continue with the planning instructions for the installation location you want to use: 


+ “Each Node in the Cluster” on page 108 
¢ “Shared Volume” on page 109 


Each Node in the Cluster 


Make sure you have filled out item 5 on the Messenger Clustering Worksheet with a complete list of 
nodes in the cluster. Skip to “Planning the Messenger Agent Installation” on page 109. 
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11.1.4 


Shared Volume 


For convenience throughout the rest of this section, the term “Messenger volume” means “a cluster- 
enabled shared volume where the Messenger agents are installed.” Complete the following planning 
tasks for the Massager volume: 

¢ “Selecting the Messenger Volume” on page 109 

¢ “Determining an Appropriate Failover Path for the Messenger Volume” on page 109 


¢ “Selecting IP Address Resolution Methods for the Messenger Volume” on page 109 


Selecting the Messenger Volume 


If you are not planning to enable archiving, or if you are not anticipating a large Messenger archive, 
you can use one Messenger volume. If you anticipate archiving a large number of messages so that 
the Messenger archive grows very large, you might want to have a separate Messenger volume for 
the Archive Agent and the archive database. The steps in this section cover setting up the Messenger 
agents on a single Messenger volume. 


MESSENGER CLUSTERING WORKSHEET 
Under Item 9: Shared Volume for Messenger Agents, record the name and IP address of the 
Messenger volume. 


Determining an Appropriate Failover Path for the Messenger Volume 


By default, a Messenger volume is configured to have all nodes in the cluster in its failover path, 
organized in ascending alphanumeric order. Only one node at a time can have the Messenger volume 
mounted and active. If a Messenger volume’s preferred node fails, the volume fails over to the next 
node in the failover path. 


MESSENGER CLUSTERING WORKSHEET 

Under Item 10: Failover Path for Messenger Volume, list the nodes that you want to have in the 
Messenger volume failover path. The Messenger agents might need to run on any node that the 
Messenger volume fails over to. 


Selecting IP Address Resolution Methods for the Messenger Volume 


Because you are using a cluster-enabled volume for the Messenger agents, you must ensure that short 
name resolution is always successful. For background information, see Section 2.7, “Ensuring 
Successful Name Resolution for GroupWise Volumes,” on page 25. 


MESSENGER CLUSTERING WORKSHEET 
Under Item 11: IP Address Resolution Methods, mark the short name address resolution methods you 


want to implement to ensure that the UNC paths stored in ConsoleOne can be successfully resolved 
into the physical network address of the Messenger volume. 


Planning the Messenger Agent Installation 


Aside from the cluster-specific issues discussed in the preceding sections, the considerations 
involved in planning to install the Messenger agents are the same in a clustering environment as for 
any other environment. Review “Planning Your Novell Messenger System”, then print and fill out 
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the “Novell Messenger Worksheet” in “Installing a Novell Messenger System” in the Novell 
Messenger 2.1 Installation Guide. Transfer the following information from the Messenger Clustering 
Worksheet to the Messenger System Worksheet: 


+ For Item 3: Installation Path on the Messenger System Worksheet: 
+ If you are installing the Messenger agents to each node in the cluster, use sys: \system. 


+ If you are installing the Messenger agents to a Messenger volume, use volume: \systen, 
where volume is the name of the Messenger volume from Item 9: Shared Volume for 
Messenger Administration on the Messenger Clustering Worksheet. 


¢ Under Item 12: Server Address on the Messenger System Worksheet: 


+ If you are installing the Messenger agents to each node in the cluster, use the cluster IP 
address from Item 3: Cluster Identification on the Messenger Clustering Worksheet. 


+ Ifyou are installing the Messenger agents to a Messenger volume, specify the Messenger 
volume IP address from Item 9: Shared Volume for Messenger Agents on the Messenger 
Clustering Worksheet. 


+ Under Item 13: Configure Agents for Clustering? on the Messenger System Worksheet, mark Yes. 
This adds the /cluster switch to the agent startup files. The /cluster switch tells the Messenger 
agents to use the virtual server name of the cluster or the Messenger volume rather than the 
specific server name in pathnames obtained from agent object properties in Novell eDirectory or 
from startup switches. This enables the Messenger agents to access the location no matter which 
node it is currently running on. This applies to the agents’ working directory, queue directory, 
log file directory, and so on. 


+ Under Item 14: Admin Configuration on the Messenger System Worksheet: 


¢ If you are installing the Messenger snap-in to ConsoleOne to an administrator workstation, 
use the location where ConsoleOne is already installed (typically 
c:\novell\consoleone\version_number). 


¢ If you are installing the Messenger snap-in to ConsoleOne to a shared volume, use 
volume: \directory, where volume is the name of the Messenger administration volume 
from Item 7: Shared Volume for Messenger Administration on the Messenger Clustering 
Worksheet and directory is typically \public. 


Continue with Setting Up Your Messenger System in a Cluster. 
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You should have already reviewed Section 11.1, “Planning Your Messenger System in a Cluster,” on 
page 107 and filled out the Section 11.3, “Messenger Clustering Worksheet,” on page 115 and the 
“Novell Messenger Worksheet” in the Novell Messenger 2.1 Installation Guide. Follow the instructions 
for the installation location you have chosen: 

¢ Section 11.2.1, “Installing to Each Node in the Cluster,” on page 111 


+ Section 11.2.2, “Installing to a Messenger Volume,” on page 111 
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11.2.1 


11.2.2 


Installing to Each Node in the Cluster 


There are two methods of installing the Messenger agents to each node in the cluster: 
+ Run the Messenger Installation program multiple times in order to install the agent software and 
to create the agent startup files on each node in the cluster. 
¢ Run the Messenger Installation program, then copy the Messenger agent software and startup 


files to each node in the cluster. 


Use whichever method you prefer, following the steps provided in “Starting the Messenger 
Installation Program” and “Creating Your Messenger System” in “Installing a Novell Messenger 
System” in the Novell Messenger 2.1 Installation Guide. Make each node in the cluster active to make 
sure that the Messenger agents start successfully. 


Installing to a Messenger Volume 


Complete the following tasks to set up your Messenger system on a Messenger volume: 


¢ “Preparing the Cluster for Messenger” on page 111 
¢ “Running the Messenger Installation Program” on page 111 


+ “Configuring the Messenger Volume Resource to Load and Unload the Messenger Agents” on 
page 112 


¢ “Copying LDAP and QuickFinder Files to the Messenger Volume” on page 113 
+ “Testing Your Clustered Messenger System” on page 113 


Preparing the Cluster for Messenger 


Cluster preparation for Messenger is the same as cluster preparation for GroupWise. Review 
Section 3.1, “Preparing the Cluster for GroupWise,” on page 39 before running the Messenger 
installation program. 


Running the Messenger Installation Program 


The Messenger Installation program walks you through setting up your Messenger system and 
installing the Messenger agents. 


1 Ifnecessary, map a drive to the Messenger administration volume (Messenger Clustering 
Worksheet item 7). 
2 Map a drive to the Messenger volume (Messenger Clustering Worksheet item 9). 


The Messenger volume name will be cluster_volume. For assistance with mapping a drive toa 
cluster-enabled volume, see “Configuring Short Name Resolution” on page 40. 
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3 Run the Messenger Installation program at an administrator workstation to set up your 
Messenger system, following the steps provided in “Starting the Messenger Installation 
Program” and “Creating Your Messenger System” in “Installing a Novell Messenger System” in 
the Novell Messenger 2.1 Installation Guide. Keep in mind the following cluster-specific details: 


+ When you specify the Messenger installation directory, be sure to browse to the location 
through the Messenger volume accessed in Step 2 above. 


+ When you specify the ConsoleOne directory, be sure to browse to the location through the 
Messenger administration volume accessed in Step 1 above. 


+ On the Start Copying Files page, the server object name should be the virtual server name, 
not a physical server name. 


4 When you have finished creating your Messenger system, continue with Configuring the 
Messenger Volume Resource to Load and Unload the Messenger Agents. 


Configuring the Messenger Volume Resource to Load and Unload the Messenger 
Agents 
The properties of the Volume Resource object define how the Messenger volume functions within the 
cluster, how the Messenger agents are loaded and unloaded, and how failover and failback situations 
are handled. 
1 In ConsoleOne, browse to and select the Cluster object. 
If necessary, click View > Console View to display its contents. 


2 Right-click the Volume Resource object (volume_SERVER), then click Properties > Load to display 
the default volume resource load script for the Messenger volume. 


The volume resource load script executes whenever the Messenger volume comes online. 


3 Add the following lines to the load script: 


load volume: \novell\nm\ma\nmma.nlm @volume:novell\nm\ma\strtup.ma 
load volume: \novell\nm\aa\nmaa.nlm @volume:novell\nm\aa\strtup.aa 


where volume is the name of the Messenger volume (Messenger Clustering Worksheet item 9). 


For example: 


load msgr:\novell\nm\ma\nmma.nlm @msgr:novell\nm\ma\strtup.ma 
load msgr:\novell\nm\aa\nmaa.nlm @msgr:novell\nm\aa\strtup.aa 


As an alternative, you can start both Messenger agents with a single command: 


volume: \novell\nm\nmstart .ncf 
4 Click Apply to save the load script. 
5 Click Unload. 
6 Add the following lines to the unload script: 


unload nmma.nlm 
unload nmaa.nlm 


7 Click Apply to save the unload script. 
8 Click Nodes to display the default failover path for the Messenger volume. 


9 Arrange the nodes in the cluster into the desired failover path for the Messenger volume 
(Messenger Clustering Worksheet item 10). 


10 Click Apply to save the failover path. 
11 Click Policies to display the default start, failover, and failback policies. 
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By default, a volume resource: 
¢ Fails over automatically if the node it is running on fails 
¢ Starts automatically on the net node in its failover path 


¢ Continues running at its failover location even after its most preferred node is again 
available 


12 Change the policies if necessary, then click OK. 
13 Continue with Copying LDAP and QuickFinder Files to the Messenger Volume. 


Copying LDAP and QuickFinder Files to the Messenger Volume 


During installation of the Messenger agents, some files were copied to sys: \system of the node 
where the Messenger volume was mounted. These files must be copied one time to the cluster 
volume that is hosting the Messenger agents. 


From the node where the Messenger volume was mounted during installation, copy the following 
files to the cluster volume: 


Table 11-2 LDAP and QuickFinder Files to Copy 


Copy From: Copy To: 

sys:\system\ldapsdk.nlm clustervol:\system\ma 
sys:\system\ldapssl.nlm clustervol:\system\ma 
sys: \system\ldapx.nlm clustervol:\system\ma 
sys:\system\qfind217.nlm clustervol:\system\aa 


If you are running in a language other than English, copy the following files from the appropriate 
numbered language subdirectory on the NetWare server to the cluster volume: 


Table 11-3 Language-Specific Files to Copy 


Copy From: Copy To: 
sys: \system\nls\language_code\nmma.msg clustervol:\system\ma 
sys: \system\nls\language_code\nmaa.msg clustervol:\system\aa 


Continue with Testing Your Clustered Messenger System. 


Testing Your Clustered Messenger System 


After you have configured the Messenger volume resource, you can test the load and unload scripts 
by bringing the Messenger volume online and taking it offline again. 


1 In ConsoleOne, select the Cluster object, then click View > Cluster State. 
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@ GWVOL_SERVER Offline GW-CLUSTER1 
@ ILVOL_SERVER Running GW-CLUSTER1 


The new Messenger volume resource shows Offline in the State column. 








2 Click the new Messenger volume resource, then click Online. 


Running GW-CLUSTER1 
Running GW-CLUSTER1 











The State column for the volume resource now displays Running. 


3 Observe the server console where the Messenger agents are loading to see that they start and run 
correctly. 


4 Click the new Messenger volume resource, then click Offline. 
The State column for the volume resource returns to Offline. 


5 Observe the server console where the Messenger agents are unloading to see that they shut 
down correctly. 


6 Repeat Step 2 whenever you are ready to bring the new Messenger volume resource online 
permanently. 


On NetWare 6.5, these actions can also be performed from your Web browser. See “Using Novell 
Remote Manager on NetWare 6.5” on page 56. 
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Messenger Clustering Worksheet 


Item 


1) Software Version Updates 
for Cluster: 


+ Latest ConsoleOne Snap-in for 
Novell Cluster Services 


2) eDirectory Tree for Cluster: 


3) Cluster Identification: 
Cluster Name: 


Cluster IP Address: 


4) Cluster Context: 


5) Nodes in Cluster 


6) Installation Location for Messenger 
Administration: 


+ Administrator workstation(s) 


+ Shared volume 


7) Shared Volume for Messenger 
Administration: 


Cluster Volume IP Address: 


Installation Location for Messenger 
Snap-In to ConsoleOne: 


+ /public directory 
+ Other directory 


Explanation 


Mark any updates that the nodes in your cluster need in order 
to meet the system requirements for Messenger system in a 
cluster. 


To review the background information provided for GroupWise 
clustering, see Section 2.1, “Meeting Software Version 
Requirements,” on page 20. 


Record the eDirectory tree where you created the Novell 
Cluster object when you installed Novell Cluster Services. 


To review the background information provided for GroupWise 
clustering, see Section 2.2, “Installing Novell Cluster Services,” 
on page 20. 


Record the name of the name of the NetWare Cluster object 
where your Messenger system will be located. Also record the 
virtual IP address of the cluster that will remain constant 
regardless of which node is currently active. 


To review the background information provided for GroupWise 
clustering, see Section 2.2, “Installing Novell Cluster Services,” 
on page 20. 


Record the full context where you created the NetWare Cluster 
object. 


To review the background information provided for GroupWise 
clustering, see Section 2.2, “Installing Novell Cluster Services,” 
on page 20. 


List the nodes that are part of the cluster. 


To review the background information provided for GroupWise 
clustering, see Section 2.2, “Installing Novell Cluster Services,” 
on page 20. 


Mark the location where you will install the Messenger snap-in 
to ConsoleOne. For more information, see “Planning 
Messenger Administration” on page 107. 


If you plan to install the Messenger snap-in to ConsoleOne on 
a shared volume, specify the name (cluster_volume) of the 
shared volume where you will install it. 


Specify the IP addresses of the virtual server 
(volume_SERVER.cluster) to which the shared volume is tied. 


Specify the directory where you will install the Messenger 
snap-in to ConsoleOne on the shared volume. 


To review the background information about cluster-enabled 
volumes provided for GroupWise, see Section 2.6, “Deciding 
Whether to Cluster-Enable the Shared Volumes Used by 
GroupWise,” on page 23. 
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Item 


8) Installation Location for Messenger 
Agents: 


+ Each node in the cluster 


+ Shared volume 


9) Shared Volume for Messenger 
Agents: 


Cluster volume IP address: 


10) Failover Path for Messenger Shared 
Volume: 


11) IP Address Resolution Methods: 


+ eDirectory 

+ hosts file 

¢ DNS 

+ SLP (highly recommended) 
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Explanation 


Mark the location where you will install the Messaging Agent 
software. 


For more information, see “Deciding Where to Install the 
Messenger Agent Software” on page 108. 


If you plan to install the Messenger agents on a shared 
volume, specify the name (cluster_volume) of the shared 
volume. 


Specify the IP address of the virtual server 
(volume_SERVER.cluster) to which the cluster-enabled 
volume is tied. 


To review the background information about cluster-enabled 
volumes provided for GroupWise, see Section 2.6, “Deciding 
Whether to Cluster-Enable the Shared Volumes Used by 
GroupWise,” on page 23. 


For more information, see “Selecting the Messenger Volume” 
on page 109. 


If you plan to install the Messenger agents on a shared 
volume, list other nodes in the cluster where the Messenger 
agents could fail over. 


For more information, see “Determining an Appropriate 
Failover Path for the Messenger Volume” on page 109. 


Mark the short name address resolution methods you want to 
implement to ensure that the UNC paths stored in ConsoleOne 
can be successfully resolved into physical network addresses. 


To review the background information provided for GroupWise, 
see Section 2.7, “Ensuring Successful Name Resolution for 
GroupWise Volumes,” on page 25. 


Novell Cluster Services on Linux 


¢ Chapter 12, “Introduction to GroupWise 8 and Novell Cluster Services on Linux,” on page 119 
+ Chapter 13, “Planning GroupWise in a Linux Cluster,” on page 121 

+ Chapter 14, “Setting Up a Domain and a Post Office in a Linux Cluster,” on page 131 

¢ Chapter 15, “Implementing the Internet Agent in a Linux Cluster,” on page 153 

+ Chapter 16, “Implementing WebAccess in a Linux Cluster,” on page 175 

¢ Chapter 17, “Implementing GroupWise Monitor in a Linux Cluster,” on page 195 

¢ Chapter 18, “Backing Up a GroupWise System in a Linux Cluster,” on page 209 

+ Chapter 19, “Updating a GroupWise System in a Linux Cluster,” on page 211 

¢ Chapter 20, “Moving an Existing Linux GroupWise 8 System into a Linux Cluster,” on page 213 
¢ Chapter 21, “Moving a Clustered GroupWise 8 System from NetWare to Linux,” on page 215 


+ Chapter 22, “Implementing Messenger in a Linux Cluster,” on page 217 
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Introduction to GroupWise 8 and Novell 
Cluster Services on Linux 


Before implementing GroupWise 8 with Novell Cluster Services on Linux, make sure you have a 
solid understanding of Novell Cluster Services by reviewing the OES Linux Clustering 
documentation (http://www.novell.com/documentation/oes2/cluster-services.html#cluster). When 
you review this information, you discover that clustering employs very specialized terminology. The 
following brief glossary provides basic definitions of clustering terms and relates them to your 
GroupWise system: 


cluster: A grouping of from two to 32 servers configured using Novell Cluster Services so that data 
storage locations and applications can transfer from one server to another without interrupting their 
availability to users. 





NOTE: Although a cluster can include both Linux and NetWare servers, GroupWise components on 
Linux servers can fail over only to other Linux servers. 


node: A clustered server; in other words, a single server that is part of a cluster. 


shared disk system: The hardware housing the physical disks that are shared among the cluster 
nodes. 


shared partition: A disk partition in a shared disk system that can be accessed from any cluster node 
that needs the data stored on it. On Linux, Novell Cluster Services supports shared partitions (Linux 
traditional file system disk partitions), shared NSS volumes (Novell Storage Services volumes), and 
shared pools (virtual servers). 





NOTE: For simplicity, this section uses the term “shared partition” to represent any of these three 
storage configuration alternatives. For more information, the OES 11 Novell Cluster Services 2 for Linux 
Administration Guide (http://www.novell.com/documentation/oes11/clus_admin_lx/data/ 
h4hgu4hs.html). 


cluster-enabled shared partition: A shared partition for which a Cluster Resource object has been 
created in Novell eDirectory. The properties of the Cluster Resource object provide load and unload 
scripts for applications and services installed on the partition, failover/failback/migration policies for 
the applications and services, and the failover list for the partition. 





IMPORTANT: Cluster-enabling is required for GroupWise. For more information, see the OES 11 
Novell Cluster Services 2 for Linux Administration Guide (http://www.novell.com/documentation/oes11/ 
clus_admin_Ix/data/h4hgu4hs.html). 





GroupWise partition: As used in this section, a cluster-enabled shared partition that is used for 
GroupWise, such as for housing a domain, a post office, or a software distribution directory. 


Messenger partition: As used in this section, a cluster-enabled shared partition that is used for 
Messenger, such as for storing conversation files, log files, temporary files, queue directories, etc. 
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cluster resource: A shared partition, secondary IP address, application, service, Web server, etc., that 
can function successfully anywhere in the cluster. Cluster resources include the GroupWise agents 
and the Messenger agents. 


failover: The process of moving cluster resources from a failed node to a functional node so that 
availability to users is uninterrupted. For example, if the node where the POA is running goes down, 
the POA and its post office fail over to a secondary node so that users can continue to use GroupWise. 
When setting up cluster resources, you must consider what components need to fail over together in 
order to continue functioning. 


fan-out-failover: The configuration where cluster resources from a single failed node fail over to 
several different nodes in order to distribute the load from the failed node across multiple nodes. For 
example, if a node runs a cluster resource consisting of a domain and its MTA, another cluster 
resource consisting of a post office and its POA, and a third cluster resource for the Internet Agent, 
each cluster resource could be configured to fail over separately to different secondary nodes. 


failback: The process of returning cluster resources to their preferred node after the situation causing 
the failover has been resolved. For example, if a POA and its post office fail over to a secondary node, 
that cluster resource can be configured to fail back to its preferred node when the problem is 
resolved. 


migration: The process of manually moving a cluster resource from its preferred node to a secondary 
node for the purpose of performing maintenance on the preferred node, temporarily lightening the 
load on the preferred node, etc. 
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Planning GroupWise in a Linux Cluster 


The majority of this part of the GroupWise 8 Interoperability Guide (Chapter 13, “Planning GroupWise 
in a Linux Cluster,” on page 121 through Chapter 18, “Backing Up a GroupWise System in a Linux 
Cluster,” on page 209) is designed for those who are creating a new GroupWise system, or at least 
new domains and post offices, in the context of Novell Cluster Services on Linux. 


If you already have an existing GroupWise 8 system on OES Linux and need to configure it to work 
in a newly installed cluster, see Chapter 20, “Moving an Existing Linux GroupWise 8 System into a 
Linux Cluster,” on page 213. If you already have an existing clustered GroupWise 8 system on OES 
NetWare, see Chapter 21, “Moving a Clustered GroupWise 8 System from NetWare to Linux,” on 
page 215. 


When you implement a new GroupWise system or a new domain or post office in a clustering 
environment, overall GroupWise system design does not need to change substantially. For a review, 
see “Installing a Basic GroupWise System” in the GroupWise 8 Installation Guide. However, the 
configuration of individual components of your GroupWise system will be significantly different. 
This section helps you plan the following GroupWise components in a cluster: 

+ Anew GroupWise system consisting of the primary domain and the initial post office 

+ Anew secondary domain 

+ Anew post office 

+ The GroupWise agents: Message Transfer Agent (MTA) and Post Office Agent (POA) 
During the planning process, component configuration alternatives are explained. For example, you 


might want the domain and post office together on the same shared partition or on different shared 
partitions. 


Section 13.7.1, “System Clustering Worksheet,” on page 128 lists the information you need as you set 
up GroupWise in a clustering environment. You should print the worksheet and fill it out as you 
complete the tasks listed below: 

¢ Section 13.1, “Installing Novell Cluster Services on Linux,” on page 122 

+ Section 13.2, “Planning a Clustered Software Distribution Directory,” on page 123 

¢ Section 13.3, “Planning a New Clustered Domain,” on page 124 

+ Section 13.4, “Planning a New Clustered Post Office,” on page 125 

è Section 13.5, “Planning a New Library for a Clustered Post Office,” on page 125 


+ Section 13.6, “Deciding How to Install and Configure the Linux Agents in a Cluster,” on 
page 126 


+ Section 13.7, “GroupWise Clustering Worksheets,” on page 127 


After you have completed the tasks and filled out Section 13.7.1, “System Clustering Worksheet,” on 
page 128 and Section 13.7.2, “Agent Clustering Worksheet,” on page 129, you are ready to continue 
with Chapter 14, “Setting Up a Domain and a Post Office in a Linux Cluster,” on page 131. 
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Installing Novell Cluster Services on Linux 


Install Novell Cluster Services on OES Linux by following the instructions provided in the OES 11 
Novell Cluster Services 2 for Linux Administration Guide (http://www.novell.com/documentation/oes11/ 
clus_admin_Ix/data/h4hgu4hs.html) . 


The cluster installation process includes: 


+ Meeting hardware and software requirements 

+ Setting up a shared disk system 

+ Creating a new Cluster object to represent the cluster in Novell eDirectory 
e Adding nodes to the cluster 

¢ Installing the Novell Cluster Services software on all nodes in the cluster 


¢ Creating shared partitions, shared NSS volumes, or shared pools as needed for your cluster, as 
described in the OES 11 Novell Cluster Services 2 for Linux Administration Guide (http:// 
www.novell.com/documentation/oes11/clus_admin_lx/data/h4hgu4hs.html). 


NOTE: For simplicity in this section, the term “shared partition” is intended to include any of 
these shared storage alternatives. 





¢ Cluster-enabling any of these shared storage alternatives, as described in the OES 11 Novell 
Cluster Services 2 for Linux Administration Guide (http://www.novell.com/documentation/oes11/ 
clus_admin_Ix/data/h4hgu4hs.html). 





IMPORTANT: Cluster-enabling is required for GroupWise. 





+ Mounting the shared partitions where you want to set up GroupWise domains and post offices. 


As you install Novell Cluster Services on Linux, record key information about the cluster on the 
System Clustering Worksheet: 


SYSTEM CLUSTERING WORKSHEET 


Under Item 1: eDirectory Tree for Cluster, record the name of the eDirectory tree where the new 
Cluster object has been created. 


Under Item 2: Cluster Name, record the name of the Cluster object that you created for your 
GroupWise system. 


Under Item 3: Cluster Context, record the full context of the Cluster object. 


Under Item 4: Nodes in Cluster, list the nodes that you have added to the cluster. Include the file 
system information about each partition, including file system type (reiserfs, ext3, etc.), device 
name (sda2, hdal, etc.), and mount point directory (/mnt, /mail, etc.). You need this information 
when you set up the load and unload scripts for the GroupWise cluster resources. 


Under Item 5: Shared Partitions, list the shared partitions that are available for use in your GroupWise 
system. 
The number of nodes and shared partitions that are available in the cluster strongly influences where 


you can place GroupWise domains and post offices. You have several alternatives: 


¢ Your whole GroupWise system can run in a single cluster. 
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+ Parts of your GroupWise system can run in one cluster while other parts of it run in one or more 
other clusters. 


¢ Parts of your GroupWise system can run in a cluster while other parts run outside of the cluster, 
on non-clustered servers. 


If you do not have the system resources to run all of your GroupWise system in a clustering 
environment, you must decide which parts have the most urgent need for the high availability 
provided by clustering. Here are some suggestions: 


+ Post offices and their POAs must be available in order for users to access their GroupWise 
mailboxes. Therefore, post offices and their POAs are excellent candidates for the high 
availability provided by clustering. 


+ Domains and their MTAs are less noticeable to users when they are unavailable (unless users in 
different post offices happen to be actively engaged in an e-mail discussion when the MTA goes 
down). On the other hand, domains and their MTAs are critical to GroupWise administrators, 
although administrators might be more tolerant of a down server than end users are. Critical 
domains in your system would be the primary domain and, if you have one, a hub or routing 
domain. These domains should be in the cluster, even if other domains are not. 


¢ The Internet Agent might or might not require high availability in your GroupWise system, 
depending on the importance of immediate messaging across the Internet and the use of POP3 
or IMAP4 clients by GroupWise users. 


¢ The Monitor Agent is a vital partner with the GroupWise High Availability service, described in 
“Enabling the Groupwise High Availability Service for the Linux GroupWise Agents” in 
“Installing GroupWise Agents” in the GroupWise 8 Installation Guide. The High Availability 
service automatically restarts agents that go down under circumstances that do not cause the 
entire server to go down. If you want this protection for your GroupWise agents, you can run the 
Monitor Agent in your cluster. 


There is no right or wrong way to implement GroupWise in a clustering environment. It all depends 
on the specific needs of your particular GroupWise system and its users. 


Planning a Clustered Software Distribution Directory 


During creation of a GroupWise system, you are prompted to create a software distribution directory. 
You can create the software distribution directory on each node where you install the GroupWise 
software or you can create it on a GroupWise partition so that you install it only once but it is still 
always available. 





IMPORTANT: You must the software distribution directory in a location that is available to all nodes 
in the cluster if you want to take advantage of the Configure GroupWise for Clustering option of the 
Installation program. This option simplifies the process of installing the agent software to multiple 
nodes in the cluster. It eliminates the need to provide the same agent configuration information 
multiple times. The installation instructions in this section are based on using the Configure 
GroupWise for Clustering option of the Installation program. 





For background information about software distribution directories, see “Software Directory 
Management” in “System” in the GroupWise 8 Administration Guide. 
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SYSTEM CLUSTERING WORKSHEET 


If you want to have your GroupWise software distribution directory as part of your cluster, under Item 
6: GroupWise Partition for Software Distribution Directory, list the GroupWise partition and associated 
secondary IP address for the software distribution directory. List the full path for the software 
distribution directory, regardless of whether it is located on a GroupWise partition or on each node in 
the cluster. 


Planning a New Clustered Domain 


The considerations involved in planning a new domain in a clustering environment are essentially 
the same as for any other environment. 


¢ Primary Domain: If you are setting up a new GroupWise system in a clustering environment, 
you are creating the primary domain as you complete the tasks in this section. To prepare, 
review “Planning a Basic GroupWise System”, then print and fill out the “Basic GroupWise 
System Summary Sheet” in “Installing a Basic GroupWise System” in the GroupWise 8 
Installation Guide. This covers planning the primary domain and an initial post office in the 
primary domain. 


+ Secondary Domain: If your GroupWise system already exists, you are creating a new secondary 
domain. To prepare, review “Planning a New Domain’, then print and fill out the “Domain 
Worksheet” in “Domains” in the GroupWise 8 Administration Guide. 


Regardless of the type of domain you are creating, keep in mind the following cluster-specific details 
as you fill out the worksheet you need: 


¢ When you specify the location for the domain directory (and for anew GroupWise system, the 
post office directory) on the worksheet, remember that it will be on a GroupWise partition, not 
on the node where you will be running the GroupWise Installation program. 


+ Do not concern yourself with the GroupWise agent information on the worksheet. You will plan 
the agent installation later. If you are filling out the Basic GroupWise System Worksheet, stop 
with Post Office Settings. If you are filling out the Domain Worksheet, stop with Domain 
Administrator. 


When you have completed the worksheet, transfer the key information from the Basic GroupWise 
System Worksheet or the Domain Worksheet to the System Clustering Worksheet. 


SYSTEM CLUSTERING WORKSHEET 


Under Item 9: Domain Name, transfer the domain name and database directory to the System 
Clustering Worksheet. 


Under Item 7: GroupWise Partition for Domain, transfer the domain location to the System Clustering 
Worksheet. Also specify the secondary IP address of the shared partition where you plan to create 
the domain. 





IMPORTANT: Do not create the new domain until you are instructed to do so in Chapter 14, “Setting 
Up a Domain and a Post Office in a Linux Cluster,” on page 131. 
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13.5 


Planning a New Clustered Post Office 


The considerations involved in planning a new post office in a clustering environment are essentially 
the same as for any other environment. The initial post office in a new GroupWise system is planned 
on the Basic GroupWise System Worksheet. To plan additional new post offices, review “Planning a 
New Post Office ”, then print and fill out the “Post Office Worksheet” in “Post Offices” in the 
GroupWise 8 Administration Guide. When you specify the location for the post office directory, 
remember that it will be on a GroupWise partition, not on the node where you will be running the 
GroupWise Installation program. 


When you have completed the worksheet, transfer key information from the Basic GroupWise 
System Worksheet or the Post Office Worksheet to the System Clustering Worksheet. 


SYSTEM CLUSTERING WORKSHEET 


Under Item 10: Post Office Name, transfer the post office name and database location to the System 
Clustering Worksheet. Also specify the secondary IP address of the shared partition where you plan to 
create the domain. 


If you will create the post office on a different GroupWise partition from where the domain is located, 
under Item 8: Shared Partition for Post Office, transfer the post office location to the System Clustering 
Worksheet. Also specify the secondary IP address of the shared partition where you plan to create the 
post office. 





IMPORTANT: Do not create the new post office until you are instructed to do so in Chapter 14, 
“Setting Up a Domain and a Post Office in a Linux Cluster,” on page 131. 





Planning a New Library for a Clustered Post Office 


The considerations involved in planning a new library in a clustering environment are essentially the 
same as for any other environment. However, in a Linux cluster, you should not plan to locate a 
document storage area on a remote storage area. If you choose to place it outside the post office 
directory structure, it should still be located on the same server with the post office. 


You can plan a library for a clustered post office by following the standard instructions provided in 
“Creating and Managing Libraries” in the GroupWise 8 Administration Guide and filling out the “Basic 
Library Worksheet” or the “Full-Service Library Worksheet”. Then provide the library information 
on the System Clustering Worksheet. 


SYSTEM CLUSTERING WORKSHEET 


Under Item 11: Document Storage Area Location, mark where you want to create the library’s 
document storage area. 





IMPORTANT: Do not create the new library until you are instructed to do so in Chapter 14, “Setting 
Up a Domain and a Post Office in a Linux Cluster,” on page 131. 
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13.6 


13.6.1 


13.6.2 


Deciding How to Install and Configure the Linux Agents ina 
Cluster 


There are several cluster-specific issues to consider as you plan to install the Linux MTA and POA in 
your clustered GroupWise system: 


+ Section 13.6.1, “Recording Secondary IP Addresses for the Agents,” on page 126 
¢ Section 13.6.2, “Determining Appropriate Failover Lists for the Agents,” on page 126 
+ Section 13.6.3, “Determining Cluster Resource Information for the Linux Agents,” on page 127 


¢ Section 13.6.4, “Planning the Linux Agent Installation,” on page 127 


Recording Secondary IP Addresses for the Agents 


By default, the GroupWise agents listen on all IP addresses, both primary and secondary, that are 
bound to the server. This means that any time there is a possibility of two of the same type of agent 
loading on the same node, it is important that each agent use the appropriate secondary IP address of 
the GroupWise partition. The secondary IP address moves with each agent when it fails over, so that, 
in the case of the POA, GroupWise clients do not lose their connections to the POA. When you use 
the Configure GroupWise for Clustering option, the GroupWise Installation program sets the --ip switch 
in each agent startup file to its unique secondary IP address. 


If you are going to set up a GroupWise name server to help GroupWise clients locate their post 
offices, make sure that the default POA port number of 1677 is used somewhere in the cluster. For 
more information, see “Simplifying Client/Server Access with a GroupWise Name Server” in “Post 
Office Agent” in the GroupWise 8 Administration Guide. 


AGENT CLUSTERING WORKSHEET 


Under Item 3: MTA Network Information, transfer the domain secondary IP address from the System 
Clustering Worksheet to the Agent Clustering Worksheet. 


Under Item 6: POA Network Information, transfer the post office secondary IP address from the 
System Clustering Worksheet to the Agent Clustering Worksheet. 


Determining Appropriate Failover Lists for the Agents 


By default, a GroupWise partition is configured to have all nodes in the cluster in its failover list, 
organized in ascending alphanumeric order. Only one node at a time can have a particular 
GroupWise partition mounted and active. If a GroupWise partition’s preferred node fails, the 
partition fails over to the next node in the failover list. You should customize the failover list for each 
GroupWise partition based on the fan-out-failover principle. 


When a node fails, its partitions should not all fail over together to the same secondary node. Instead, 
the partitions should be distributed across multiple nodes in the cluster. This prevents any one node 
from shouldering the entire processing load typically carried by another node. In addition, some 
partitions should never have the potential of being mounted on the same node during a failover 
situation. For example, a post office and POA that service a large number of very active GroupWise 
client users should never fail over to a node where another very large post office and heavily loaded 
POA reside. If they did, users on both post offices would notice a decrease in responsiveness of the 
GroupWise client. 
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13.6.3 


13.6.4 


13.7 


AGENT CLUSTERING WORKSHEET 


Under Item 2: Domain Failover List, list the nodes that you want to have in the domain partition failover 
list. The MTA might need to run on any node that the domain partition fails over to. Therefore, you will 
install the agent software on all of the nodes in the domain failover list. 


If you are planning the post office on a different GroupWise partition from where the domain is located, 
under Item 5: Post Office Failover List, list the nodes that you want to have in the post office partition 
failover list. The POA might need to run on any node that the post office partition fails over to. Therefore, 
you will install the agent software on all of the nodes in the post office failover list. 


Determining Cluster Resource Information for the Linux Agents 


A cluster resource is a shared partition, secondary IP address, application, service, Web server, etc., 
that can function successfully anywhere in the cluster. Cluster resources include the GroupWise 
agents and the Messenger agents. When using the Configure GroupWise for Clustering option, the 
GroupWise Installation program needs to know the mount point for the GroupWise partition where 
it will create the domain and post office. For example, you might create a /mnt /gwsystem mount 
point, or you might create /mnt/dom1 and /mnt/po1 mount points. The Installation program also 
needs to know the secondary IP address of the GroupWise partition. 


AGENT CLUSTERING WORKSHEET 


Under Item 7: Cluster Resource Information, list the mount point and secondary IP address for the 
GroupWise partition where the domain and post office will be located. 


Planning the Linux Agent Installation 


Aside from the cluster-specific issues discussed in the preceding sections, the considerations 
involved in planning to install the GroupWise Linux agents are the same in a clustering environment 
as for any other environment. Review “Planning the GroupWise Agents”, then print and fill out the 
“GroupWise Agent Installation Summary Sheet” in “Installing GroupWise Agents” in the GroupWise 
8 Installation Guide for each location where you will install the Linux MTA and/or POA. 





IMPORTANT: Do not install the Linux agent software until you are instructed to do so in 
Chapter 14, “Setting Up a Domain and a Post Office in a Linux Cluster,” on page 131. 





Skip to Chapter 14, “Setting Up a Domain and a Post Office in a Linux Cluster,” on page 131. 


GroupWise Clustering Worksheets 


+ Section 13.7.1, “System Clustering Worksheet,” on page 128 
+ Section 13.7.2, “Agent Clustering Worksheet,” on page 129 


Planning GroupWise in a Linux Cluster 127 


13.7.1 


128 


System Clustering Worksheet 


Item 


1) eDirectory Tree for Cluster: 


2) Cluster Name: 


Master IP Address: 


3) Cluster Context: 


4) Nodes in Cluster: 


+ File system type 
+ Device name 


+ Mount point directory 


5) Shared Partitions in Cluster: 


6) GroupWise Partition for Software 
Distribution Directory: 


Secondary IP Address: 


Directory: 


7) GroupWise Partition for Domain: 
Secondary IP Address: 


Post Office on Same Partition as 
Domain? 


+ Yes 


+ No 


8) GroupWise Partition for Post Office: 


Secondary IP Address: 
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Explanation 


Record the eDirectory tree where you created the new Novell 
Cluster object when you installed Novell Cluster Services. 


For more information, see Section 13.1, “Installing Novell 
Cluster Services on Linux,” on page 122 


Record the name of the new Cluster object that you created for 
your GroupWise system. Also record the virtual IP address of 

the cluster that will remain constant regardless of which node 

is currently active. 


For more information, see Section 13.1, “Installing Novell 
Cluster Services on Linux,” on page 122. 


Record the full context where you created the new Cluster 
object. 


For more information, see Section 13.1, “Installing Novell 
Cluster Services on Linux,” on page 122. 


List the nodes that are part of the cluster that you set up for 
your GroupWise system. Also list the file system type 
(reiserfs, ext3, etc.), device name (sda2, hdal, etc.), and 
mount point directory (/mnt, /mail, etc.) for each. You need 
this information as you create load and unload scripts for 
GroupWise agents. 


For more information, see Section 13.1, “Installing Novell 
Cluster Services on Linux,” on page 122. 


List the shared partitions that are available for use in your 
GroupWise system. 


For more information, see Section 13.1, “Installing Novell 
Cluster Services on Linux,” on page 122. 


If desired, specify the name of the shared partition where the 
GroupWise software distribution directory will reside and the 
full path to its location. 


For more information, see Section 13.2, “Planning a Clustered 
Software Distribution Directory,” on page 123. 


Specify the name of the shared partition where the GroupWise 
domain will reside and its secondary IP address. 


For more information, see Section 13.3, “Planning a New 
Clustered Domain,” on page 124. 


Specify the name of the shared partition where the GroupWise 
post office will reside and its secondary IP address. 


For more information, see Section 13.4, “Planning a New 
Clustered Post Office,” on page 125. 


13.7.2 


Item 


9) Domain Name: 


Domain Directory: 


10) Post Office Name: 


Post Office Directory: 


11) Document Storage Area Location: 


+ At the post office 
+ Outside the post office 


+ Separate post office 


Explanation 


Specify a unique name for the domain. Specify the directory on 
the GroupWise partition where you want to create the new 
domain. 


For more information, see Section 13.3, “Planning a New 
Clustered Domain,” on page 124. 


Specify a unique name for the post office. Specify the directory 
on the GroupWise partition where you want to create the post 
Office. 


For more information, see Section 13.4, “Planning a New 
Clustered Post Office,” on page 125. 


If you need a library for a clustered post office, mark where you 
want to create its document storage area and provide a 
directory if necessary. 


For more information, see Section 13.5, “Planning a New 
Library for a Clustered Post Office,” on page 125. 


Agent Clustering Worksheet 


Item 
1) Domain Name: 
Domain Location: 


2) Domain Failover List: 


3) MTA Network Information: 


+ MTA IP address 
+ MTA message transfer port 


+ MTA HTTP port 
4) Post Office Name: 
Post Office Location: 


5) Post Office Failover List: 


Explanation 


Transfer this information from the System Clustering 
Worksheet (item 9). 


List other nodes in the cluster where the GroupWise domain 
and its MTA could fail over. 


For more information, see Section 13.6.2, “Determining 
Appropriate Failover Lists for the Agents,” on page 126. 


Record the MTA network address information for the server 
where the MTA will run. The MTA IP address is the same as the 
domain secondary IP address in the cluster. 


See Section 13.6.1, “Recording Secondary IP Addresses for 
the Agents,” on page 126. 


Transfer this information from the System Clustering 
Worksheet (item 10). 
List other nodes in the cluster where the GroupWise post office 


and its POA could fail over. 


For more information, see Section 13.6.2, “Determining 
Appropriate Failover Lists for the Agents,” on page 126. 
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Item 
6) POA Network Information: 


+ POA IP address 
+ POA client/server port 
+ POA message transfer port 


+ POA HTTP port 
7) Cluster Resource Information 


+ Path to the cluster resource mount 
point 


+ IP address of the cluster resource 
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Explanation 


Record the POA network address information for the server 
where the POA will run. The POA IP address is the same as 
the post office secondary IP address in the cluster. 


See Section 13.6.1, “Recording Secondary IP Addresses for 
the Agents,” on page 126. 


List the cluster resource information for the GroupWise partition 
where the domain and post office serviced by the agents are 
located. 


For more information, see Section 13.6.3, “Determining Cluster 
Resource Information for the Linux Agents,” on page 127. 


Setting Up a Domain and a Post Office in 
a Linux Cluster 


You should have already reviewed Chapter 13, “Planning GroupWise in a Linux Cluster,” on 
page 121 and filled out the Section 13.7.1, “System Clustering Worksheet,” on page 128 and the 
Section 13.7.2, “Agent Clustering Worksheet,” on page 129. You are now ready to complete the 
following tasks to set up GroupWise in a clustering environment on Linux: 

è Section 14.1, “Setting Up a New GroupWise System in a Linux Cluster,” on page 131 

è Section 14.2, “Creating a New Secondary Domain in a Linux Cluster,” on page 132 

+ Section 14.3, “Creating a New Post Office in a Linux Cluster,” on page 133 

+ Section 14.4, “Installing and Configuring the MTA and the POA in a Cluster,” on page 134 

+ Section 14.5, “Testing Your Clustered GroupWise System,” on page 147 

+ Section 14.6, “Managing Your Clustered GroupWise System,” on page 148 

è Section 14.7, “What’s Next,” on page 150 

+ Section 14.8, “Clustering Quick Checklists,” on page 151 


14.1 Setting Up a New GroupWise System in a Linux Cluster 


The GroupWise Installation program walks you through setting up the primary domain and an 
initial post office in the primary domain. You might be creating your primary domain and initial post 
office on the same GroupWise partition or on two different partitions. After you have created the 
primary domain and initial post office and then installed the GroupWise agents on multiple nodes in 
the cluster, you can create additional secondary domains and post offices as needed. 


To set up the primary domain and initial post office for a new GroupWise system in a clustering 
environment: 


1 Start with the first node on the domain failover list (Agent Clustering Worksheet item 2). 


2 Make sure that ConsoleOne is installed on the node. 


If necessary, you can download ConsoleOne for Linux from the Novell Product Downloads site 
(http://download.novell.com). ConsoleOne is always installed in /usr/Consoleone. 


3 Ifnecessary, mount the GroupWise partition where you want to create the GroupWise software 
distribution directory (System Clustering Worksheet item 6). 


4 Mount the GroupWise partition for the domain (System Clustering Worksheet item 7) and, if 
needed, the GroupWise partition for the post office (System Clustering Worksheet item 8), 
where the primary domain and the initial post office for your new GroupWise system will be 
created. 


5 Run the GroupWise Installation program, as described in “Starting the Linux GroupWise 
Installation Program” in “Installing a Basic GroupWise System” in the GroupWise 8 Installation 
Guide. 
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14.2 


10 





IMPORTANT: Do not select the Configure GroupWise for Clustering option at this time. 





When you set up the software distribution directory, install all the agent software. 


Although this is not required when creating your initial domain and post office, it makes 
installation of the other GroupWise agents easier after you have created the initial domain and 
post office. 


From the Installation program, run ConsoleOne to set up your initial GroupWise system, as 
described in “Using ConsoleOne to Create Your Basic GroupWise System” in “Installing a Basic 
GroupWise System” in the GroupWise 8 Installation Guide. 


When providing the MTA and POA network address information, use the Agent Clustering 
Worksheet that you filled out in Section 13.6, “Deciding How to Install and Configure the Linux 
Agents in a Cluster,” on page 126. The information you provide is used to configure the MTA 
and POA objects in the domain and post office even though you have not yet installed the agent 
software on any nodes in the cluster. 


Do not create users in the post office at this time. 


When you have finished creating the primary domain and the initial post office, click Finish to 
exit the GroupWise Installation program without installing the agent software. 


Skip to “Running the GroupWise Installation Program on the Preferred Node” on page 134. 


Creating a New Secondary Domain in a Linux Cluster 


After you have set up the primary domain and initial post office, as described in Section 14.1, “Setting 
Up a New GroupWise System in a Linux Cluster,” on page 131, you can create additional secondary 
domains in your GroupWise system as needed. 


To create a new secondary domain in a clustering environment: 


1 
2 


Mount the GroupWise partition where the new secondary domain will be created. 


In ConsoleOne, connect to the primary domain in your GroupWise system, as described in 
“Connecting to a Domain” in “Domains” in the GroupWise 8 Administration Guide. 


Create the new domain, following the steps provided in “Creating the New Domain” in 
“Domains” in the GroupWise 8 Administration Guide. 


Use the Domain Worksheet you filled out in Section 13.3, “Planning a New Clustered Domain,” 
on page 124 to fill in the fields in the Create GroupWise Domain dialog box. 


In the Link to Domain field, link the new domain to the primary domain of your GroupWise 
system. 


Use the Link Configuration tool to change the links from the new domain to all other domains in 
the cluster to direct TCP/IP links, following the steps provided in “Changing the Link Protocol 
between Domains to TCP/IP” in “Message Transfer Agent” in the GroupWise 8 Administration 
Guide. 


Although a complete mesh link configuration is the most efficient, it might not be feasible in all 
situations. Set up as many direct TCP/IP links as possible for best MTA performance in the 
cluster. 


Make sure you are still connected to the primary domain. 


Rebuild the domain database for the new domain, following the steps provided in “Rebuilding 
Domain or Post Office Databases” in “Databases” in the GroupWise 8 Administration Guide. 
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The database rebuild is necessary in order to transfer the MTA configuration information and 
the domain link information into the secondary domain database, because the MTA for the new 
domain is not yet running. 


8 Skip to Installing and Configuring the MTA and the POA in a Cluster to install the MTA 
software for the new domain. 


Creating a New Post Office in a Linux Cluster 


You can create a new post office on the same GroupWise partition where its domain resides or ona 
separate GroupWise partition. If the post office and its domain are on the same GroupWise partition, 
they fail over together. If they are on separate GroupWise partitions, they fail over separately. 


To create a new post office in a clustering environment on Linux: 


1 Mount the GroupWise partition where the domain that will own the new post office located. 
2 If necessary, mount the GroupWise partition for the new post office 


3 In ConsoleOne, connect to the GroupWise domain where you want to create the new post office, 
as described in “Connecting to a Domain” in “Domains” in the GroupWise 8 Administration 
Guide. 


4 Create the new post office, following the steps provided in “Creating the New Post Office” in 
“Post Offices” in the GroupWise 8 Administration Guide. 


Use the Post Office Worksheet you filled out in Section 13.4, “Planning a New Clustered Post 
Office,” on page 125 to fill in the fields in the Create GroupWise Post Office dialog box. 


5 Refer to the Agent Clustering Worksheet that you filled in during Section 13.6, “Deciding How 
to Install and Configure the Linux Agents in a Cluster,” on page 126 for the secondary IP 
address and port numbers that you need to specify in order to configure the link. 


6 If you want to create a library at the post office, select Create Library. 


This option creates the document storage area for the library under the post office directory and 
is not recommended for large libraries. 


7 Right-click the new POA object, then click Properties. 


On the POA Agent Settings and Scheduled Events pages, you might want to specify unique 
times for the following POA activities to prevent multiple POAs from performing the same 
activities on the same node at the same time during a failover situation: 


¢ Start User Upkeep 

+ Generate Address Book for Remote 
¢ Enable QuickFinder Indexing 

¢ Mailbox/Library Maintenance Event 


For more information about these repetitive POA activities, see “Performing Nightly User 
Upkeep”, “Regulating Indexing”, and “Scheduling Database Maintenance” in “Post Office 
Agent” in the GroupWise 8 Administration Guide. 


8 Make sure you are still connected to the domain that owns the new post office. 


9 Rebuild the post office database for the new post office, following the steps provided in 
“Rebuilding Domain or Post Office Databases” in “Databases” in the GroupWise 8 Administration 
Guide. Be sure to browse to the database location (under System Clustering Worksheet item 11) 
through the GroupWise partition. 


The database rebuild is necessary in order to transfer the POA configuration information and 
the post office link information into the post office database, because the POA for the new post 
office is not yet running. 
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14.4.1 


10 If you want to create a library with its document storage area outside the post office directory, 
follow the steps in “Setting Up a Basic Library” or “Setting Up a Full-Service Library” in 
“Libraries and Documents” in the GroupWise 8 Administration Guide, after you have completely 
finished setting up the clustered post office. 


11 Continue with Installing and Configuring the MTA and the POA in a Cluster to install the POA 
software for the new post office. 


Installing and Configuring the MTA and the POA ina 
Cluster 


By following the instructions in Section 14.1, “Setting Up a New GroupWise System in a Linux 
Cluster,” on page 131, you installed the MTA and the POA on the first node in your cluster, as well as 
created the initial domain and post office in your GroupWise system. You are now ready to install 
and configure the agents on additional nodes and set up the agent software for use in your cluster. 

+ Section 14.4.1, “Installing and Setting Up the Agents in Your Cluster,” on page 134 

è Section 14.4.2, “Changing Agent Paths to Locations on GroupWise Partitions,” on page 138 


è Section 14.4.3, “Configuring GroupWise Cluster Resources to Load and Unload the Agents,” on 
page 139 

+ Section 14.4.4, “Setting Up New Instances of the Agents without Installing the Agent Software,” 
on page 146 


If you have added a new secondary domain or a new post office to an existing GroupWise system, 
the agent software has already been installed and you simply need to create a new startup file 
specific to the new domain or post office. In these circumstances, follow the instructions in 

Section 14.4.4, “Setting Up New Instances of the Agents without Installing the Agent Software,” on 
page 146 instead of completing the tasks above. 


Installing and Setting Up the Agents in Your Cluster 


The agents must be installed on each node in domain failover list (Agent Clustering Worksheet item 
2) and the post office failover list (Agent Clustering Worksheet item 5). 

¢ “Running the GroupWise Installation Program on the Preferred Node” on page 134 

+ “Running the GroupWise Installation Program on Subsequent Nodes” on page 136 

¢ “Testing Your Agent Installation on Each Node” on page 137 


After you have installed and tested the agents on each node in the cluster, continue with 
Section 14.4.2, “Changing Agent Paths to Locations on GroupWise Partitions,” on page 138. 


Running the GroupWise Installation Program on the Preferred Node 


1 Mount the GroupWise partition for the domain (System Clustering Worksheet item 7) or the 
post office (System Clustering Worksheet item 8). 


2 From the software distribution directory you created in Step 6 in Section 14.1, “Setting Up a New 
GroupWise System in a Linux Cluster,” on page 131, start the GroupWise Installation program. 





IMPORTANT: This time, you should select the Configure GroupWise for Clustering option. 
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Select the language for this installation from the 
choices below. 





English x| 


= Configure GroupWise for clustering 





3 Install the agent software, following the steps provided in “Installing the GroupWise Agents on 
Linux” in “Installing GroupWise Agents” in the GroupWise 8 Installation Guide. 


4 Configure the Linux agents according to the Section 13.7.2, “Agent Clustering Worksheet,” on 
page 129 that you filled out in Section 13.6, “Deciding How to Install and Configure the Linux 
Agents in a Cluster,” on page 126, paying special attention to the cluster resource information on 
the Domains / Post Offices page. 





h _ Domain/Post Office Information 





© Domain w Post Office 


Location | OK 





Name: 


——— a 


Path to database: 


el 


Path to the Cluster Resource mount point: 


i 


IP address of the cluster resource: 


= 











As a result of selecting Configure GroupWise for Clustering on the preferred node, the following 
cluster-specific configuration actions are performed: 


¢ The agent startup files are created in mount_point/groupwise/agents/share on the 
shared resource so that the agents use the same startup files regardless of which cluster 
node the agents are running on. The --home switch includes the mount point and the path 
to the database so that the startup file is valid when mounted to each cluster node. 


¢ The --cluster switch is added to the agent startup files to inform the agents that they are 
running in a cluster. 


¢ The --ip startup switch is set to the secondary IP address of the shared resource where the 
domain and post office are located. This ensures that the MTA and the POA run with the 
same IP address regardless of which cluster node the agents are running on. 


¢ The --log startup switch is set to a location on the shared resource (mount_point/ 
groupwise/agents/log) so that agent logging information is written to the same log file 
regardless of which cluster node the agents are running on. 


+ The GroupWise High Availability service is automatically configured on the current cluster 
node and its configuration file (gwha. conf) is created in the /etc/opt /novell/groupwise 
directory. 
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¢ Aclusterimport .conf file is created in the gwinst subdirectory of the software 
distribution directory from which you ran the GroupWise Installation program, so that the 
cluster-specific information collected when you configured the agents on the preferred 
node is available when you install the agents on subsequent nodes. 


¢ The agents are not configured to start automatically on system startup. In a cluster, you do 
not want the agents to start automatically whenever a node restarts. 


5 Configure the agents to run as a non-root user, as described in the applicable section of the 
GroupWise 8 Installation Guide: 


¢ “Running the Linux GroupWise Agents As a Non-root User” 
¢ “Setting Up Non-root Access on an NSS Volume on Novell Open Enterprise Server Linux” 


6 Continue with Running the GroupWise Installation Program on Subsequent Nodes. 


Running the GroupWise Installation Program on Subsequent Nodes 


1 On the next node in the GroupWise agent failover list, mount the GroupWise partition for the 
domain (System Clustering Worksheet item 7) or the post office (System Clustering Worksheet 
item 8). 


2 From the software distribution directory you created in Step 6 in Section 14.1, “Setting Up a New 
GroupWise System in a Linux Cluster,” on page 131, start the GroupWise Installation program. 


IMPORTANT: You should select the Configure GroupWise for Clustering option again. 





` GroupWise ©) wara 





Select the language for this installation from the | 
choices below. 





English xÍ 


W Configure GroupWise for clustering 





Because of the existence of the clusterimport .conf file in the gwinst subdirectory of the 
software distribution directory, a new installation option, Import Clustering Data, is now available 
on the main GroupWise Installation program page. 


_ Novell. GroupWise» N 

View the Readme Displays a web paye with important information you should read before installing, 

View the Quickstart Displays a high-level checklist of system requirements and installation steps to guide you through setting 
up your GroupWise system. 

View the Installation Guide Displays overview and task information that will help you plan, install, and update a GroupWise system, 
as well as install additional components such as GroupWise WebAccess and GroupWise Intemet Agent. 

Create or update a GroupWise system Launches the GroupWise Installation and Setup Advisors. These advisors step you through the creation 

Li á i of anew GroupWise system orthe updating of an existing GroupWise system. 

Install Products Displays the GroupWise components you can individually install once you've created a Groupwise 
system, 

Import Clustering Data Import custering data from previously configured products, 

Visit the Novell GroupWise Web Site Launches your Web browser to display GroupWise information located on the Novell Web site, 
(http:/wwu.novell.com? 
products /yroupwise), 
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3 Install the agent software on the cluster node as usual, but do not use the Configure option. 


4 On the main page of the Installation program, click Import Clustering Data, then click Next. 





` _ Import Clustering Data ©] Ss 


Import Data 
[X] introduction Select the cluster data you would like to import and click Next. 
C import Data 
ðo Provo3 - /mntigwsystem 


Marketing - /mntigwsystem 


Select all Deselect all | 





Cancel Previous 





All GroupWise agents that you have installed from the software distribution directory are listed, 
based on the information stored in the clusterimport . conf file. 


Select the GroupWise agents that you want to configure on the current cluster node, then click 
OK. 


The Import Clustering Data option performs the following configuration actions for each 
subsequent node where you run it: 


¢ The grpwise script is created in the /etc/init.d directory on the current cluster node. It is 
configured specifically for the agents you just selected. 


¢ The GroupWise High Availability service is automatically configured on the current cluster 
node and its configuration file (gwha. conf) is created in the /etc/opt /novell/groupwise 
directory. It is configured specifically for the agents you just selected. 


Because the agent startup files and log files are stored on the shared resource, they do not need 
to be customized for each cluster node. 


Configure the agents to run as a non-root user, as described in the applicable section of the 
GroupWise 8 Installation Guide: 


¢ “Running the Linux GroupWise Agents As a Non-root User” 
¢ “Setting Up Non-root Access on an NSS Volume on Novell Open Enterprise Server Linux” 
Repeat Step 1 through Step 6 for each cluster node in the GroupWise agent failover list. 


After you install and configure the agents on each node in each agent's failover list, the cluster 
node is ready for the GroupWise agent to fail over to it. 


8 Continue with Testing Your Agent Installation on Each Node. 


Testing Your Agent Installation on Each Node 


1 Test the agents by starting them with a user interface, as described in “Starting the Linux Agents 
with a User Interface” in “Installing GroupWise Agents” in the GroupWise 8 Administration 
Guide. 


/opt/novell/groupwise/agents/bin/gwmta --show @domain.mta & 
/opt /novell/groupwise/agents/bin/gwpoa --show @post_office.poa & 
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2 Stop the agents by clicking File > Exit 


3 After you can see that the agents start successfully, test them by starting them as daemons, as 
described in “Starting the Linux GroupWise Agents as Daemons” in “Installing GroupWise 
Agents” in the GroupWise 8 Administration Guide. 


/etc/init.d/grpwise start 
/etc/init.d grpwise status 


4 Stop the agents. 


/etc/init.d/grpwise stop 
/etc/init.d grpwise status 


5 Return to “Running the GroupWise Installation Program on the Preferred Node” on page 134 
for each node in the domain or post office failover list. 


When you have installed the agents on all of the nodes in the domain and post office failover lists, 
continue with Changing Agent Paths to Locations on GroupWise Partitions. 


Changing Agent Paths to Locations on GroupWise Partitions 


The default locations for some agent files are on the cluster nodes along with the agent software, 
rather than being located with the domain and post office on one or more GroupWise partitions. To 
avoid having multiple copies of these files in multiple locations, you should set the locations in 
ConsoleOne. 

¢ “Setting the MTA Message Log File Path” on page 138 

¢ “Setting the MTA Certificate and Key File Path” on page 138 


¢ “Setting the POA Certificate and Key File Path” on page 139 


Setting the MTA Message Log File Path 


If you plan to enable message logging, as described in “Enabling MTA Message Logging” in 
“Message Transfer Agent” in the GroupWise 8 Administration Guide: 


1 On the GroupWise partition where the domain is located, create the directory where you want to 
store MTA message log files. 

In ConsoleOne, browse to and select the Domain object. 

Right-click the MTA object, then click Properties. 

Click GroupWise > Message Log Settings. 
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In the Message Log File Path field, browse to and select the directory you created in Step 1, then 
click OK. 


Setting the MTA Certificate and Key File Path 


If you plan to enable SSL, as described in “Securing the Domain with SSL Connections to the MTA” 
in “Message Transfer Agent” in the GroupWise 8 Administration Guide: 


1 On the GroupWise partition where the domain is located, create the directory where you want to 
store the certificate and key file required for SSL. 
2 Copy the certificate file and key file into the new directory. 


If you need assistance obtaining these files, see “Server Certificates and SSL Encryption” in 
“Security Administration” in the GroupWise 8 Administration Guide. 
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3 In ConsoleOne, browse to and select the Domain object. 

4 Right-click the MTA object, then click Properties. 

5 Click GroupWise > SSL Settings. 

6 In the Certificate File field, browse to and select the certificate file. 
7 Inthe SSL Key File field, browse to and select the key file. 

8 Click OK. 


Setting the POA Certificate and Key File Path 


If you plan to enable SSL, as described in “Securing the Post Office with SSL Connections to the 
POA” in “Post Office Agent” in the GroupWise 8 Administration Guide: 


1 On the GroupWise partition where the post office is located, create the directory where you 
want to store the certificate and key file required for SSL. 
2 Copy the certificate file and key file into the new directory. 


If you need assistance obtaining these files, see “Server Certificates and SSL Encryption” in 
“Security Administration” in the GroupWise 8 Administration Guide. 


In ConsoleOne, browse to and select the Post Office object. 
Right-click the POA object, then click Properties. 

Click GroupWise > SSL Settings. 

In the Certificate File field, browse to and select the certificate file. 
In the SSL Key File field, browse to and select the key file. 

Click OK. 
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14.4.3 Configuring GroupWise Cluster Resources to Load and Unload the 
Agents 


The properties of the Cluster Resource object associated with the GroupWise partition define how 
partitions function within the cluster, how agents are loaded and unloaded, and how failover and 
failback situations are handled. At this point, you might have one cluster resource for a GroupWise 
partition with a domain and post office on it, or you might have two cluster resources for two 


GroupWise partitions, one for the domain and one for the post office. Complete the following tasks 
for each cluster resource: 


e “Modifying the Cluster Resource Load Script for the Agents” on page 139 
e “Modifying the Cluster Resource Unload Script for the Agents” on page 143 
¢ “Setting the Failover List and Policies for the Agents” on page 145 


Modifying the Cluster Resource Load Script for the Agents 


The cluster resource load script executes whenever the GroupWise partition comes online. On OES 
Linux, all cluster management activities are performed in Novell iManager. 


To set up the load script in iManager: 


1 Expand Clusters, then click Cluster Options. 
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2 In the Cluster field, browse to the Cluster object where the GroupWise cluster resource is located. 
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3 Click the Cluster object to display the cluster resources that belong to the cluster. 
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4 Select the GroupWise Cluster Resource object that you created when you set up the GroupWise 
partition, then click Details. 


5 Click Scripts > Load Script. 
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6 If this is an NSS volume or a shared pool, use a load script similar to the following example, 
depending on the configuration of your cluster and nodes: 


#!/bin/bash 
/opt/novell/ncs/lib/nesfuncs 


# mount filesystem 
exit_on_error ncpcon mount /opt="noatime,nodiratime" volume_name=volume_ID 


# add IP address 
exit_on_error add_secondary_ipaddress gw partition ip address 


# start service 

exit_on_error /etc/init.d/grpwise start domain 

exit _on_error /etc/init.d/grpwise start post _office.domain 
exit_on_error /etc/init.d/grpwise start gwdva 





6a Inthe mount filesystem section, specify the volume name and volume ID of the 
GroupWise partition that you are clustering (System Clustering Worksheet item 5). 


6b Inthe add IP address section, specify the secondary IP address of the GroupWise 
partition (System Clustering Worksheet item 7 or System Clustering Worksheet item 8). 


6c Inthe start service section, use the commands to start the specific GroupWise agents 
that you want to run on this GroupWise partition. 


If you created a domain on the partition, you need to start the MTA. If you created a post 
office on the partition, you need to start the POA. If you created both a domain and a post 
office, you need to start both the MTA and the POA. If you installed the DVA, you need to 
start it as well. 


7 If this is a traditional Linux volume, use a load script similar to the following example, 
depending on the configuration of your cluster and nodes: 


#! /bin/bash 
/opt/novell/nces/lib/ncsfunc 


# define IP address 
RESOURCE IP=gw_partition_ip address 


# define filesystem type 
MOUNT_FS=filesystem 


# define device (if using EVMS) 

exit_on error evms -f /var/opt/novell/ncs/ContainerActivate -rl 
TaS Share ‘uname -n' 

MOUNT_DEV=/dev/evms/Share/dat 


# define mount point 


Setting Up a Domain and a Post Office in a Linux Cluster 141 


142 


MOUNT_POINT=/mnt/mount_point_directory 


# mount filesystem 


exi 


t_on error mount -t SMOUNT_FS SMOUNT_DEV SMOUNT_POINT -o noatime,nodiratime 


# add IP address 


exi 


# s 
exi 
exi 
exi 


exit 


7a 


7b 


7c 


7d 


t_on error add_secondary_ipaddress SRESOURCE_IP 


tart service 

t_on_error /etc/init.d/grpwise start domain 

t_on_error /etc/init.d/grpwise start post_office.domain 
t_on_error /etc/init.d/grpwise start gwdva 





0 


In the define IP address section, specify the secondary IP address of the GroupWise 
partition (System Clustering Worksheet item 7 or System Clustering Worksheet item 8) 


In the define filesystem type section, specify the filesystem type that is in use on the 
nodes in the cluster (System Clustering Worksheet item 5). 


In the define mount point section, specify the mount point directory in use for the nodes 
in the cluster (System Clustering Worksheet item 5). 


In the start service section, use the commands to start the specific GroupWise agents 
that you want to run on this GroupWise partition. 


If you created a domain on the partition, you need to start the MTA. If you created a post 
office on the partition, you need to start the POA. If you created both a domain and a post 
office, you need to start both the MTA and the POA. If you installed the DVA, you need to 
start it as well. 


8 Click OK to save the load script. 
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Modifying the Cluster Resource Unload Script for the Agents 


The cluster resource unload script executes whenever the GroupWise partition goes offline. 
Programs should be unloaded in the reverse order of how they were loaded. This ensures that 
supporting programs are not unloaded before programs that rely on them in order to function 


properly. 


1 On the Cluster Resource Properties page of the GroupWise cluster resource, click Scripts > 
Unload Script. 


2 If this isan NSS volume or a shared pool, use an unload script similar to the following example, 
depending on the configuration of your cluster and nodes: 


#!/bin/bash 
/opt/novell/ncs/lib/ncsfuncs 


# request service stop 

ignore error /etc/init.d/grpwise stop domain 

ignore error /etc/init.d/grpwise stop post_office.domain 
ignore error /etc/init.d/grpwise stop gwdva 


# stop service otherwise 
sleep 8 
ignore error pkill -fx "/opt/novell/groupwise/agents/bin/gwmta 
@/media/nss/volume_name/groupwise/agents/share/domain_name.mta" 
ignore error pkill -fx "/opt/novell/groupwise/agents/bin/gwpoa 
a @/media/nss/volume_name/groupwise/agents/share/ 
post_office_name.poa" 
ignore error pkill -fx "/opt/novell/groupwise/agents/bin/gwdva 
@/media/nss/volume_name/groupwise/agents/share/gwdva.dva" 


# delete IP address 
ignore error del secondary _ipaddress gw partition ip address 








# unmount filesystem 
exit_on_error umount /mnt/mount_point directory 


# return status 
exit 0 


2a Inthe request service stop section, use the commands to stop the specific GroupWise 
agents that are running on this GroupWise partition. 


2b Inthe stop service otherwise section, adjust the sleep command as needed so that the 
agents can shut down normally on your system without being inadvertently killed by the 
pkill command that follows. 


2c Inthe delete IP address section, specify the secondary IP address of the GroupWise 
partition. 


2d Inthe unmount filesystem section, specify the mount point directory in use for the nodes 
in the cluster. 


2e (Conditional) If you are running the GroupWise High Availability service (gwha), stop it 
before the script stops the agents, then start it again at the end of the unload script. 


This prevents the GroupWise High Availability service from trying to restart the agents 
while the script is trying to stop them. 


Add the following section before the request service stop section: 
# Temporarily disable the gwha service under xinetd 


ignore error /sbin/chkconfig -s gwha off 
ignore error kill -HUP “pidof xinetd~ 
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Add the following section before the return status section: 


# Restart the gwha service under xinetd 
ignore error /sbin/chkconfig -s gwha on 
ignore error kill -HUP “pidof xinetd~ 


3 (Conditional) If this is a traditional Linux volume, use an unload script similar to the following 
example, depending on the configuration of your cluster and nodes: 


#!/bin/bash 
/opt/novell/ncs/lib/ncsfuncs 


# request service stop 

ignore error /etc/init.d/grpwise stop domain 

ignore error /etc/init.d/grpwise stop post_office.domain 
ignore error /etc/init.d/grpwise stop gwdva 


# stop service otherwise 
sleep 8 
ignore error pkill -fx "/opt/novell/groupwise/agents/bin/gwmta 
@/media/nss/volume_name/groupwise/agents/share/domain_name.mta" 
ignore error pkill -fx "/opt/novell/groupwise/agents/bin/gwpoa 
@/media/nss/volume_name/groupwise/agents/share/ 
post_office_name.poa" 


# define IP address 
RESOURCE IP=gw_partition_ip address 


# define mount point 
MOUNT_POINT=/mnt/mount_point_directory 


# delete IP address 
ignore_error del _secondary_ipaddress SRESOURCE_IP 


# unmount filesystem 
exit_on_error umount SMOUNT_POINT 


# return status 
exit 0 


3a Inthe request service stop section, use the commands to stop the specific GroupWise 
agents that are running on this GroupWise partition. 


3b Inthe stop service otherwise section, adjust the sleep command as needed so that the 
agents can shut down normally on your system without being inadvertently killed by the 
pkill command that follows. 


3c Inthe define IP address section, specify the secondary IP address of the GroupWise 
partition. 


3d In the define mount point section, specify the mount point directory in use for the nodes 
in the cluster. 


3e (Conditional) If you are running the GroupWise High Availability service (gwha), stop it 
before the script stops the agents, then start it again at the end of the unload script. 


This prevents the GroupWise High Availability service from trying to restart the agents 
while the script is trying to stop them. 


Add the following section before the request service stop section: 
# Temporarily disable the gwha service under xinetd 


ignore error /sbin/chkconfig -s gwha off 
ignore error kill -HUP “pidof xinetd~ 
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Add the following section before the return status section: 


# Restart the gwha service under xinetd 
ignore error /sbin/chkconfig -s gwha on 
ignore error kill -HUP `pidof xinetd~ 


4 Click OK to save the unload script. 


Setting the Failover List and Policies for the Agents 


1 On the Cluster Resource Properties page of the GroupWise cluster resource, click General. 
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The default policy settings are often appropriate. By default, a cluster resource: 


¢ Fails over automatically if the node it is running on fails 


¢ Starts automatically on the next node in its failover list 


¢ Continues running at its failover location, even after its most preferred node is again 


available 


If you are considering changing these defaults, see the OES 11 Novell Cluster Services 2 for 
Linux Administration Guide (http://www.novell.com/documentation/oes11/clus_admin_lx/ 
data/h4hgu4hs.html). 


2 Under Preferred Nodes, arrange the nodes in the cluster into the desired failover list for the 


domain or post office (under Agent Clustering Worksheet items 3 or 6). 


3 Click OK. 
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14.4.4 


Setting Up New Instances of the Agents without Installing the Agent 
Software 


There are two steps to setting up new instances of the agents without installing the agent software: 


+ “Creating New Startup Files” on page 146 
e “Modifying Existing Load and Unload Scripts” on page 146 


Creating New Startup Files 


Each MTA startup file is named after the domain it services, with a .mta extension. Each POA startup 
file is named after the post office it services, with a .poa extension. When you select the Configure 
GroupWise for Clustering option, the GroupWise Installation program creates agent startup files in 
mount_point/groupwise/agents/share on the shared resource. 


To create a new startup file without installing the agent software: 
1 Make a copy of an existing startup file and name it after the domain or post office that will be 
serviced by the agent. 


2 Edit the setting of the --home startup switch to point to the location of the new domain directory 
or post office directory. Be careful to maintain the syntax of the original line. 


3 Scroll down through the new startup file looking for other active (not commented out) startup 
switches, then modify them as needed for the new agent. 


4 Save the new startup file. 


5 Edit the GroupWise High Availability service configuration file (/etc/opt /novell/groupwise/ 
gwha. conf). 


6 Make a copy of the section for an existing domain and its MTA or post office and its POA, then 
modify the information for the new domain or post office and its accompanying agent. 


7 Save the gwha. conf file. 


For more information about the High Availability service, see “Enabling the Groupwise High 
Availability Service for the Linux GroupWise Agents”. 


8 Continue with Modifying Existing Load and Unload Scripts. 


Modifying Existing Load and Unload Scripts 


The agent startup file names are part of the load commands found in GroupWise cluster resource 
load scripts. 


If you created the new domain and/or post office on a new GroupWise partition, skip back to 
Section 14.4.3, “Configuring GroupWise Cluster Resources to Load and Unload the Agents,” on 
page 139 for instructions to create new load and unload scripts. 


If you created the new domain and/or post office on an existing GroupWise partition, most of the 
configuration of the cluster resource has already been done. You just need to add new service start 
and stop commands to the existing scripts. Continue with the steps below: 


To modify existing load and unload scripts: 


1 IniManager, expand Cluster, then click Cluster Options. 


2 In the Cluster field, browse to and click the Cluster object where the GroupWise cluster resource 
is located. 
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3 Select a cluster resource that contains a GroupWise partition, then click Properties > Scripts. 


4 Following the pattern of the existing service start commands, add start commands for the new 


instances of the agents you are setting up. Use Ctrl+C to copy and Ctrl+V to paste lines in the 
load script page. 


Click Apply to save the modified load script. 
Click Unload Script. 
Add corresponding service stop commands for the new instances of the agents. 


Click Apply to save the modified unload script. 
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You might want to review other properties of the Cluster Resource object, such as the failover list 
and the failover/failback/migration procedures on the General page, in light of the fact that an 
additional domain and/or post office now resides on the GroupWise partition. 


9 Change other Cluster Resource properties as needed. 
10 Click OK to save the modified properties. 


11 In the Cluster Manager, take the GroupWise partition offline and then bring it online again to 
test the new startup files and the modified load and unload scripts. If you need assistance with 
these tasks, see Testing Your Clustered GroupWise System. 


14.5 Testing Your Clustered GroupWise System 


After you have configured the GroupWise cluster resources, you can test the load and unload scripts 
by bringing the GroupWise cluster resource online and taking it offline again. 


1 IniManager, expand Clusters, then click Cluster Manager. 
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The new GroupWise cluster resource shows Offline in the State column. 


2 Click the new GroupWise cluster resource, then click Online. 
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3 Select the cluster node where you want to online the GroupWise cluster resource, then click OK. 
After a moment, the GroupWise cluster resource displays Running in the State column. 
4 At the server where the MTA and/or POA are starting, use the following command to see if they 


are running: 


/etc/init.d/grpwise status domain 
/etc/init.d/grpwise status post_office.domain 


5 Select the new GroupWise cluster resource, then click Offline. 
The State column for the GroupWise cluster resource returns to Offline. 
6 Use the same command you used in Step 4 to verify if they have stopped. 


7 Repeat Step 2 whenever you are ready to bring the new GroupWise cluster resource online 
permanently. 


8 Continue with Managing Your Clustered GroupWise System. 


14.6 Managing Your Clustered GroupWise System 


After you have set up a basic clustered GroupWise system, you should consider some long-term 
management issues. 
¢ Section 14.6.1, “Updating GroupWise Objects with Cluster-Specific Descriptions,” on page 148 
+ Section 14.6.2, “Knowing What to Expect in MTA and POA Failover Situations,” on page 150 


14.6.1 Updating GroupWise Objects with Cluster-Specific Descriptions 


After setting up your clustered GroupWise system, while the cluster-specific information is fresh in 
your mind, you should record the cluster-specific information as part of the GroupWise objects in 
ConsoleOne so that you can easily refer to it later. Be sure to update the information in the 
GroupWise objects if the configuration of your system changes. 

¢ “Recording Cluster-Specific Information for a Domain and Its MTA” on page 149 

¢ “Recording Cluster-Specific Information for a Post Office and Its POA” on page 149 


e “Recording Cluster-Specific Information for a Software Distribution Directory” on page 150 
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Recording Cluster-Specific Information for a Domain and Its MTA 


To permanently record important cluster-specific information for the domain: 


1 In ConsoleOne, browse to and right-click the Domain object, then click Properties. 


N 


In the Description field of the domain Identification page, provide a cluster-specific description of 
the domain, including the secondary IP address of its GroupWise partition. 


Click OK to save the domain description. 
Select the Domain object to display its contents. 
Right-click the MTA object, then click Properties. 
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In the Description field of the MTA Identification page, record the secondary IP address of the 
domain’s GroupWise partition. 


This information appears on the MTA server console, no matter which node in the cluster it is 
currently running on. 


7 Click Apply to save the description. 
8 Click Network Address. 


9 Inthe TCP/IP Address field, provide the secondary IP address that you provided in the 
GroupWise Installation program for use with the --ip switch in the MTA startup file. 


10 Select Bind Exclusively to TCP/IP Address. 

This records this vital information in eDirectory as well as in the MTA startup file. 
11 Click OK to save the MTA description and secondary IP address. 
12 Continue with Recording Cluster-Specific Information for a Post Office and Its POA. 


Recording Cluster-Specific Information for a Post Office and Its POA 


To permanently record important cluster-specific information for a post office: 


1 In ConsoleOne, browse to and right-click the Post Office object, then click Properties. 


N 


In the Description field of the post office Identification page, provide a cluster-specific 
description of the post office, including the secondary IP address of its GroupWise partition. 


Click OK to save the post office description. 
Select the Post Office object to display its contents. 
Right-click the POA object, then click Properties. 
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In the Description field of the POA Identification page, record the secondary IP address of the 
post office’s GroupWise partition. 


This information appears on the POA server console, no matter which node in the cluster it is 
currently running on. 


7 Click Apply to save the description. 
8 Click Network Address. 


9 Inthe TCP/IP Address field, provide the secondary IP address that you provided in the 
GroupWise Installation program for use with the --ip switch in the POA startup file. 


10 Select Bind Exclusively to TCP/IP Address. 
This records this vital information in eDirectory as well as in the POA startup file. 
11 Click OK to save the POA description and secondary IP address. 
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14.6.2 


14.7 


12 If applicable, continue with Recording Cluster-Specific Information for a Software Distribution 
Directory. 


or 


Skip to Section 14.6.2, “Knowing What to Expect in MTA and POA Failover Situations,” on 
page 150. 


Recording Cluster-Specific Information for a Software Distribution Directory 


To permanently record important cluster-specific information about a software distribution directory 
located on a GroupWise partition: 

1 In ConsoleOne, click Tools > System Operations > Software Directory Management. 

2 Select the software distribution directory, then click Edit. 


3 In the description field, record the secondary IP address of the GroupWise partition where the 
software distribution directory resides. 


4 Click OK, then click Close to save the software distribution directory description. 
5 Continue with Knowing What to Expect in MTA and POA Failover Situations. 


Knowing What to Expect in MTA and POA Failover Situations 


In a failover situation, the agents might need to perform some database repair as they start on the 
new node. The time required depends on the size of the databases involved. 


Typically, the POA returns to full functionality faster than the MTA. This benefits GroupWise client 
users, who can reconnect to their mailboxes very quickly and probably do not notice if messages to 
users in other post offices are not delivered immediately. The only time a user needs to restart the 
GroupWise client is if he or she was actually in the process of sending a message when the POA went 
down. Notify can continue running even if the connection to the POA becomes unavailable and then 
it reconnects automatically when the POA is again available. 


The MTA typically takes some time reestablishing the links to its post offices, other domains, and 
gateways, but this situation usually resolves itself in a few minutes without administrator 
intervention. If it does not, you can manually restart the MTA to speed up the process. 


In comparison to failover, migration typically takes longer because the agents methodically terminate 
their threads and close their databases as part of their normal shutdown procedure. However, as a 
result, no database repair is required when the agents start up again in their new location. 


Continue with What’s Next. 


What’s Next 


Now that you have at least one GroupWise domain and post office up and running in a clustering 
environment, you are ready to proceed with the rest of your GroupWise system setup by: 
+ Adding users to post offices. See “Users” in the GroupWise 8 Administration Guide. 


+ Setting up the GroupWise client software and helping users to get started using it. See “Client” 
in the GroupWise 8 Administration Guide. Also see the GroupWise 8 Windows Client User Guide. 


+ Connecting your clustered GroupWise system to the Internet. See Chapter 15, “Implementing 
the Internet Agent in a Linux Cluster,” on page 153. 
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¢ Providing access to users’ GroupWise mailboxes from their Web browsers. See Chapter 16, 
“Implementing WebAccess in a Linux Cluster,” on page 175. 


+ Monitoring the status of your clustered GroupWise system from your Web browser. See 
Chapter 17, “Implementing GroupWise Monitor in a Linux Cluster,” on page 195. 


¢ Backing up your clustered GroupWise system. See Chapter 18, “Backing Up a GroupWise 
System in a Linux Cluster,” on page 209. 


14.8 Clustering Quick Checklists 


è Section 14.8.1, “GroupWise System Quick Checklist,” on page 151 
è Section 14.8.2, “Domain Quick Checklist,” on page 151 
* Section 14.8.3, “Post Office Quick Checklist,” on page 152 


GroupWise System Quick Checklist 


O Plan your new clustered GroupWise system. 


See Chapter 13, “Planning GroupWise in a Linux Cluster,” on page 121. 
O Create the primary domain and initial post office in your new clustered GroupWise system. 
See Section 14.1, “Setting Up a New GroupWise System in a Linux Cluster,” on page 131. 
C Set up the agents for the primary domain and the initial post office. 
See Section 14.4, “Installing and Configuring the MTA and the POA in a Cluster,” on page 134. 
O Modify the cluster resource load scripts: 
See “Modifying the Cluster Resource Load Script for the Agents” on page 139. 
O Modify the cluster resource unload scripts: 
See “Modifying the Cluster Resource Unload Script for the Agents” on page 143. 
C Set up the cluster failover lists and policies. 
See “Setting the Failover List and Policies for the Agents” on page 145. 
O Test your new clustered GroupWise system. 
See Section 14.5, “Testing Your Clustered GroupWise System,” on page 147. 


O Record cluster-specific information in the properties pages of the GroupWise objects that the 
information pertains to. 


See Section 14.6, “Managing Your Clustered GroupWise System,” on page 148. 


Domain Quick Checklist 


C Plan your new clustered domain. 


See Section 13.3, “Planning a New Clustered Domain,” on page 124. 
O Create the new domain. 
See Section 14.2, “Creating a New Secondary Domain in a Linux Cluster,” on page 132. 
C Set up the MTA for the new domain. 
See Section 14.4, “Installing and Configuring the MTA and the POA in a Cluster,” on page 134. 
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O Modify the domain cluster resource load script. 

See “Modifying the Cluster Resource Load Script for the Agents” on page 139. 
O Modify the domain cluster resource unload script. 

See “Modifying the Cluster Resource Unload Script for the Agents” on page 143. 
O Set up the domain failover list and policies. 

See “Setting the Failover List and Policies for the Agents” on page 145. 
O Test your new clustered domain. 

See Section 14.5, “Testing Your Clustered GroupWise System,” on page 147. 


O Record cluster-specific information in the properties pages of the GroupWise objects that the 
information pertains to. 


See Section 14.6, “Managing Your Clustered GroupWise System,” on page 148. 


14.8.3 Post Office Quick Checklist 


O Plan your new clustered post office. 


See Section 13.4, “Planning a New Clustered Post Office,” on page 125 and Section 13.5, 
“Planning a New Library for a Clustered Post Office,” on page 125. 


O Create the new post office. 

See Section 14.3, “Creating a New Post Office in a Linux Cluster,” on page 133. 
C Set up the POA for the new post office. 

See Section 14.4, “Installing and Configuring the MTA and the POA in a Cluster,” on page 134. 
O Modify the post office cluster resource load script: 

See “Modifying the Cluster Resource Load Script for the Agents” on page 139. 
O Modify the post office cluster resource unload script: 

See “Modifying the Cluster Resource Unload Script for the Agents” on page 143. 
C Set up the post office failover list and policies. 

See “Setting the Failover List and Policies for the Agents” on page 145. 
O Test your new clustered post office. 

See Section 14.5, “Testing Your Clustered GroupWise System,” on page 147. 


O Record cluster-specific information in the properties pages of the GroupWise objects that the 
information pertains to. 


See Section 14.6, “Managing Your Clustered GroupWise System,” on page 148. 
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15.1 


Implementing the Internet Agent ina 
Linux Cluster 


You should already have set up at least a basic GroupWise system, as described in Chapter 13, 
“Planning GroupWise in a Linux Cluster,” on page 121 and Chapter 14, “Setting Up a Domain and a 
Post Office in a Linux Cluster,” on page 131. As part of this process, you filled you the “System 
Clustering Worksheet” on page 128. If you do not have access to the filled-out worksheet, print the 
worksheet now and fill in the clustering information as it currently exists on your system. You need 
this information as you implement the Internet Agent in a cluster. 

¢ Section 15.1, “Planning the Internet Agent in a Linux Cluster,” on page 153 

+ Section 15.2, “Setting Up the Internet Agent in a Linux Cluster,” on page 157 

+ Section 15.3, “Testing the Internet Agent in a Linux Cluster,” on page 168 

¢ Section 15.4, “Managing the Internet Agent in a Linux Cluster,” on page 170 

¢ Section 15.5, “Internet Agent Clustering Worksheet,” on page 171 


+ Section 15.6, “Internet Agent Quick Checklist,” on page 172 


Planning the Internet Agent in a Linux Cluster 


A major system configuration difference between the Internet Agent in a clustering environment and 
the Internet Agent in a regular environment is that you need to create a separate domain to house 
each GroupWise gateway, including the Internet Agent. 


The Section 15.5, “Internet Agent Clustering Worksheet,” on page 171 lists the information you need 
as you set up the Internet Agent in a clustering environment. You should print the worksheet and fill 
it out as you complete the tasks listed below: 
¢ Section 15.1.1, “Planning a Domain for the Internet Agent,” on page 154 
¢ Section 15.1.2, “Selecting the Internet Agent Partition and Secondary IP Address,” on page 154 
+ Section 15.1.3, “Determining an Appropriate Failover List for the Internet Agent,” on page 155 
è Section 15.1.4, “Determining Cluster Resource Information for the Internet Agent,” on page 155 
¢ Section 15.1.5, “Preparing DNS for the Clustered Internet Agent,” on page 155 
è Section 15.1.6, “Preparing Your Firewall for the Clustered Internet Agent,” on page 155 
¢ Section 15.1.7, “Planning the MTA Installation,” on page 156 
+ Section 15.1.8, “Planning the Internet Agent Installation,” on page 156 
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15.1.1 


15.1.2 


Planning a Domain for the Internet Agent 


The considerations involved in planning a domain for the Internet Agent are much the same as 
planning any other domain. In preparation, review “Planning a New Domain”, then print and fill out 
the “Domain Worksheet” in “Domains” in the GroupWise 8 Administration Guide. 


Keep in mind the following cluster-specific details: 


+ When you specify the location for the domain directory on the Domain Worksheet, remember 
that it is on a GroupWise partition, not on the node where you running the GroupWise 
Installation program. This location is referred to as the Internet Agent partition because it is 
where the Internet Agent message queues are located. 


+ Do not concern yourself with the GroupWise agent information on the Domain Worksheet. You 
can stop with item 10. You will plan the MTA installation later. 


When you have completed the Domain Worksheet, transfer the key information from the Domain 
Worksheet to the Internet Agent Clustering Worksheet. 


INTERNET AGENT CLUSTERING WORKSHEET 


Under Item 1: GroupWise Partition for the Internet Agent, transfer the domain location to the Internet 
Agent Clustering Worksheet. 


Under Item 2: Internet Agent Domain Name, transfer the domain name and database directory to the 
Internet Agent Clustering Worksheet. 


IMPORTANT: Do not create the new domain until you are instructed to do so in Section 15.2.1, 
“Creating a Domain for the Internet Agent,” on page 157. 





Selecting the Internet Agent Partition and Secondary IP Address 


As with the MTA and the POA, the Internet Agent needs a secondary IP address that remains the 
same no matter which node in the cluster it is running on. You can place the Internet Agent and its 
domain on a GroupWise partition where a domain or post office already reside, which means that the 
Internet Agent shares the same secondary IP address as that domain or post office and fails over 
along with that domain or post office. Or you can place the Internet Agent and its domain on its own 
GroupWise partition, which means that it has its own secondary IP address and fails over 
independently. 


INTERNET AGENT CLUSTERING WORKSHEET 


Under Item 1: GroupWise Partition for Internet Agent, specify the secondary IP address for the 
Internet Agent partition. 


Under Item 5: MTA Network Information, copy the same secondary IP address. 


Under Item 6: Internet Agent Network Information, copy the same secondary IP address. 





IMPORTANT: You must configure the GWIA to bind exclusively to the secondary IP address. Novell 
Cluster Services uses Postfix to send cluster email alerts using the primary IP address. Postfix and the 
GWIA both default to port 25. A conflict results unless you configure the GWIA so that it does not 
use the primary IP address. Instructions are provided in “Forcing Use of the Internet Agent 
Secondary IP Address” on page 167. 
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15.1.3 


15.1.4 


15.1.5 


15.1.6 


Determining an Appropriate Failover List for the Internet Agent 


By default, a GroupWise partition is configured to have all nodes in the cluster in its failover list, 
organized in ascending alphanumeric order. Only one node at a time can have a particular 
GroupWise partition mounted and active. If a GroupWise partition’s preferred node fails, the 
partition fails over to the next node in the failover list. You should customize the failover list for each 
GroupWise partition based on the fan-out-failover principle. 


As with the MTA and the POA, you need to decide which nodes in the cluster are appropriate 
locations for the Internet Agent partition to fail over to. You must install the Internet Agent software 
on all of the nodes where you want the Internet Agent to be able to fail over. For a review of failover 
lists, see Section 13.6.2, “Determining Appropriate Failover Lists for the Agents,” on page 126, which 
describes the issues in the context of planning MTA and POA installations. 


INTERNET AGENT CLUSTERING WORKSHEET 


Under Item 3: Internet Agent Failover List, list the nodes that you want in the Internet Agent partition 
failover list. 


Determining Cluster Resource Information for the Internet Agent 


A cluster resource is a shared partition, secondary IP address, application, service, Web server, etc., 
that can function successfully anywhere in the cluster. Cluster resources include the GroupWise 
agents and the Messenger agents. When using the Configure GroupWise for Clustering option, the 
GroupWise Installation program needs to know the mount point for the GroupWise partition where 
the Internet Agent domain is located. 


INTERNET AGENT CLUSTERING WORKSHEET 


Under Item 4: Cluster Resource Mount Point, list the mount point for the GroupWise partition where the 
Internet Agent domain is located. 


Preparing DNS for the Clustered Internet Agent 
In order for the Internet Agent partition to be recognized on your network, DNS must have an MX 


record that includes the hostname corresponding to the secondary IP address of the Internet Agent 
partition. A DNS A record associates the secondary IP address with the hostname. 


Preparing Your Firewall for the Clustered Internet Agent 
The Internet Agent receives incoming messages on the secondary IP address of the Internet Agent 


partition. Your firewall configuration must be modified to allow inbound TCP/IP traffic from the 
Internet to the Internet Agent secondary IP address on the following standard ports: 


Table 15-1 Standard Ports 


Protocol Standard Port 
IMAP4 143 
LDAP 389 
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15.1.8 


Protocol Standard Port 


POP3 110 
SMTP 25 


By default, the Internet Agent sends outgoing messages on the primary IP address of the server where it 
is running. If you decide to use this default configuration, your firewall must be configured to allow 
outbound TCP/IP traffic from all nodes in the Internet Agent partition failover list. 


If the Internet Agent has a large number of nodes on its failover list, you could configure the Internet 
Agent to send outgoing messages to a relay host, which then sends them out through the firewall 
using its own IP address rather than the address of the particular node where the Internet Agent was 
running. This reduces the amount of modification to your firewall required to set up the Internet 
Agent. However, if the relay host goes down, outgoing messages are delayed. 


As another alternative, you can configure the Internet Agent to use its secondary IP address for 
sending as well as receiving messages. Setup instructions for this configuration are provided in 
“Forcing Use of the Internet Agent Secondary IP Address” on page 167, which you can complete after 
installing the Internet Agent. 


In preparation for installing the Internet Agent, configure your firewall as needed to handle the 
Internet Agent’s use of primary and secondary IP addresses when sending and receiving messages. 


Planning the MTA Installation 


Follow the instructions in Section 13.6.4, “Planning the Linux Agent Installation,” on page 127, then 
return to this point. After you follow the instructions, you will have a filled-out Agent Clustering 
Worksheet to use when you install the MTA. 





IMPORTANT: Do not install the Linux MTA until you are instructed to do so in Section 15.2, “Setting 
Up the Internet Agent in a Linux Cluster,” on page 157. 





Planning the Internet Agent Installation 


Aside from the cluster-specific issues discussed in the preceding sections, the considerations 
involved in planning to install the Internet Agent are the same in a clustering environment as for any 
other environment. Review the installation instructions in “Linux: Installing the Internet Agent 
Software” in “Installing the GroupWise Internet Agent” in the GroupWise 8 Installation Guide. Use the 
“GroupWise Internet Agent Installation Summary Sheet” to record the planning information you will 
need as you install the Internet Agent in your cluster. 





IMPORTANT: Do not install the Internet Agent software until you are instructed to do so in Setting 
Up the Internet Agent in a Linux Cluster. 
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15.2 


15.2.1 


15.2.2 


15.2.3 


Setting Up the Internet Agent in a Linux Cluster 


You should already have reviewed Section 15.1, “Planning the Internet Agent in a Linux Cluster,” on 
page 153 and filled out Section 15.5, “Internet Agent Clustering Worksheet,” on page 171. You are 
now ready to complete the following tasks to set up the Internet Agent in a clustering environment: 

¢ Section 15.2.1, “Creating a Domain for the Internet Agent,” on page 157 

¢ Section 15.2.2, “Installing the MTA for the Internet Agent Domain,” on page 157 

¢ Section 15.2.3, “Installing and Configuring the Internet Agent in a Cluster,” on page 157 


Creating a Domain for the Internet Agent 


The Internet Agent domain will be a secondary domain. To create it, follow the instructions in 
Section 14.2, “Creating a New Secondary Domain in a Linux Cluster,” on page 132, taking your 
information from the Internet Agent Clustering Worksheet, rather than the System Clustering 
Worksheet, then return to this point. 


Do not create any post offices in the Internet Agent domain. 


After you have created the domain, continue with Installing the MTA for the Internet Agent Domain. 


Installing the MTA for the Internet Agent Domain 


The MTA for the Internet Agent domain can be installed just like any other MTA in your clustered 
GroupWise system. Follow the instructions in Section 14.4.1, “Installing and Setting Up the Agents in 
Your Cluster,” on page 134, then return to this point. 


You do not need to edit the MTA startup file. You do not need to modify the Cluster Resource object 
properties until after you have installed the Internet Agent. 


After you have installed the MTA, continue with Installing and Configuring the Internet Agent in a 
Cluster. 


Installing and Configuring the Internet Agent in a Cluster 


After you have created a domain for the Internet Agent and installed the MTA for that domain, you 
are ready to install and configure the Internet Agent. 

¢ “Installing and Setting Up the Internet Agent Software in Your Cluster” on page 158 

¢ “Configuring the Clustered Internet Agent for SSL” on page 161 


+e “Configuring the Internet Agent Cluster Resource to Load and Unload the Internet Agent and 
Its MTA” on page 162 


+ “Enabling Internet Addressing for Your Clustered GroupWise System” on page 167 
¢ “Forcing Use of the Internet Agent Secondary IP Address” on page 167 
¢ “Verifying Internet Agent Object Properties” on page 167 


Implementing the Internet Agent in a Linux Cluster 157 


158 


Installing and Setting Up the Internet Agent Software in Your Cluster 


The Internet Agent must be installed on each node in its failover list (Internet Agent Clustering 
Worksheet item 3). 


+ “Running the Internet Agent Installation Program on the Preferred Node” on page 158 
+ “Running the Internet Agent Installation Program on Subsequent Nodes” on page 159 


¢ “Testing Your Internet Agent Installation on Each Node” on page 161 


Running the Internet Agent Installation Program on the Preferred Node 


1 Make sure that the Internet Agent software is available in the software distribution directory you 
created in Step 6 in Section 14.1, “Setting Up a New GroupWise System in a Linux Cluster,” on 


page 131. 


2 Mount the Internet Agent partition (Internet Agent Clustering Worksheet item 1) where the 
Internet Agent message queues are located. 


3 From the software distribution directory, start the GroupWise Installation program and select 
Configure GroupWise for Clustering. 


` GroupWise ©] waka 





Select the language for this installation from the 
choices below. 





English hd] 


W Configure GroupWise for clustering 





4 Install the Internet Agent software, following the steps provided in “Linux: Installing the 
Internet Agent Software” in “Installing the GroupWise Internet Agent” in the GroupWise 8 
Installation Guide. 


Configure the Internet Agent according to the “GroupWise Internet Agent Installation Summary 
Sheet” that you filled out in Section 15.1, “Planning the Internet Agent in a Linux Cluster,” on 
page 153, paying special attention to the cluster resource information on the Server Information 


page. 
` _ GroupWise Internet Agent Configuration ©) ES 


Server Information 


x | 
E] introduction | Specify the network address of the Internet Agent. The IP address and 
| DNS host name will be the same as the Internet Agent's server. The port 
w License Agreement “number should be the port you want the Internet Agent to listen on. 


O Server Information 


| 
| IP Address: MTP Port: 





0 
oO | 
| DNS host name: 
Oo | — 
ï | 
m 


| Path to the Cluster Resource mount point: 


ie 


Cancel Previous Next 
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As a result of selecting Configure GroupWise for Clustering on the preferred node, the following 
cluster-specific configuration actions are performed: 


¢ The Internet Agent startup file (gwia.cfg) is created in mount_point/groupwise/agents/ 
share on the shared resource so that the Internet Agent uses the same startup file 
regardless of which cluster node it is running on. The --home switch includes the mount 
point and the path to the database so that the startup file is valid when mounted to each 
cluster node. 


¢ The --cluster switch is added to the Internet Agent startup file to inform the Internet Agent 
that it is running in a cluster. 


¢ The --ip startup switch is set to the secondary IP address of the shared resource where the 
domain is located. This ensures that the Internet Agent runs with the same IP address 
regardless of which cluster node it is running on. 


¢ The --log startup switch is set to a location on the shared resource (mount_point/ 
groupwise/agents/log) so that Internet Agent logging information is written to the same 
log file regardless of which cluster node it is running on. 


+ If this is the first GroupWise agent installed on this cluster node, the GroupWise High 
Availability service is automatically configured and its configuration file (gwha . conf) is 
created in the /etc/opt/novell/groupwise directory. If another GroupWise agent has 
already been installed on this cluster node, the gwha. conf file is updated to include the 
Internet Agent. 


+ The clusterimport.conf file in the gwinst subdirectory of the software distribution 
directory from which you ran the GroupWise Installation program is updated, so that the 
cluster-specific information collected when you configured the Internet Agent on the 
preferred node is available when you install the Internet Agent on subsequent nodes. 


+ The Internet Agent is not configured to start automatically on system startup. In a cluster, 
you do not want the Internet Agent to start automatically whenever a node restarts. 


6 Configure the Internet Agent to run as a non-root user, as described in the applicable section of 
the GroupWise 8 Installation Guide: 


¢ “Running the Linux GroupWise Agents As a Non-root User” 
¢ “Setting Up Non-root Access on an NSS Volume on Novell Open Enterprise Server Linux” 


7 Continue with Running the Internet Agent Installation Program on Subsequent Nodes. 


Running the Internet Agent Installation Program on Subsequent Nodes 


1 On the next node in the Internet Agent failover list, mount the Internet Agent partition (Internet 
Agent Clustering Worksheet item 1) where the Internet Agent message queues are located. 


2 From the software distribution directory you created in Step 6 in Section 14.1, “Setting Up a New 
GroupWise System in a Linux Cluster,” on page 131, start the GroupWise Installation program 
and select Configure GroupWise for Clustering. 





Ls 


Select the language for this installation from the 
choices below. 





English x| 


W Configure GroupWise for clustering 


omes | 





Because of the existence of the clusterimport . conf file in the gwinst subdirectory of the 
software distribution directory, a new installation option, Import Clustering Data, is now available 
on the main GroupWise Installation program page. 
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- Novell. GroupWise. N 
View the Readme Displays a web paye with important information you should read before installing. 
View the Quickstart Displays a high-level checklist of system requirements and installation steps to yuide you through setting 
up your GroupWise system, 
View the Installation Guide Displays overview and task information that will help you plan, install, and update a GroupWise system, 


as well as install additional components such as GroupWise WebAccess and GroupWise Intemet Agent. 


Create or update a GroupWise system Launches the GroupWise Installation and Setup Advisors. These advisors step you through the creation 
of anew GroupWise system orthe updating of an existing GroupWise system, 


Install Products Displays the GroupWise components you can individually install once you've created a GroupWise 
system, 

Import Clustering Data Import custering data from previously configured products. 

Visit the Novell GroupWise Web Site Launches your Web browserto display GroupWise information located on the Novell Web site. 
{http:Awww.novell.com? 
products /yroupwise), 





3 Install the Internet Agent software on the cluster node as usual, but do not use the Configure 
option. 


4 On the main page of the Installation program, click Import Clustering Data, then click Next. 





Import Clustering Data ROY x 








Import Data 
[E] introduction Select the cluster data you would like to import and click Next. 
CO import Data 
LJ fi [Provo3 - mntigwsystem 


| Marketing - /mntigwsystem 
GWIA - imntigwsystem 


Select all Deselect all 
Cancel Previous Next 








All GroupWise agents that you have installed from the software distribution directory are listed, 
based on the information stored in the clusterimport . conf file. 


5 Select the GroupWise agents that you want to configure on the current cluster node, then click 
OK. 


The Import Clustering Data option performs the following configuration actions for each 
subsequent node where you run it: 


¢ The grpwise script is created in the /etc/init .d directory on the current cluster node. It is 
configured specifically for the agents you just selected. 


¢ The GroupWise High Availability service is automatically configured on the current cluster 
node and its configuration file (gwha. conf) is created in the /etc/opt /novell/groupwise 
directory. It is configured specifically for the agents you just selected. 


Because the agent startup files and log files are stored on the shared resource, they do not need 
to be customized for each cluster node. 
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6 Configure the Internet Agent to run as a non-root user, as described in the applicable section of 
the GroupWise 8 Installation Guide: 


¢ “Running the Linux GroupWise Agents As a Non-root User” 
¢ “Setting Up Non-root Access on an NSS Volume on Novell Open Enterprise Server Linux” 
7 Repeat Step 1 through Step 6 for each cluster node in the Internet Agent failover list. 


After you install and configure the Internet Agent on each node in its failover list, the cluster 
node is ready for the Internet Agent to fail over to it. 


8 Continue with Testing Your Internet Agent Installation on Each Node. 


Testing Your Internet Agent Installation on Each Node 


1 Test the Internet Agent by starting it with a user interface, as described in “Linux: Starting the 
Internet Agent” in “Installing the GroupWise Internet Agent” in the GroupWise 8 Installation 
Guide. 

/opt/novell/groupwise/agents/bin/gwia --show @gwia.cfg & 

2 Stop the Internet Agent by clicking File > Exit. 


3 After you can see that the Internet Agent stopped successfully, test it by starting it as a daemon, 
as described in “Starting the Linux GroupWise Agents as Daemons” in “Installing GroupWise 
Agents” in the GroupWise 8 Installation Guide. 


/etc/inet.d/grpwise start domain.gwia 
/etc/inet.d/grpwise status domain.gwia 


4 Stop the Internet Agent. 


/etc/inet.d/grpwise stop domain.gwia 
/etc/inet.d/grpwise status domain.gwia 


5 Make sure you have completed all the tasks described in “Installing the GroupWise Internet 
Agent” in the GroupWise 8 Installation Guide. 


A few tasks, such as assigning a postmaster, are not dealt with in this cluster-oriented section. 
6 Repeat the steps in “Running the Internet Agent Installation Program on the Preferred Node” on 
page 158 for each node in the Internet Agent failover list. 


When you have installed the Internet Agent on all of the nodes in the Internet Agent failover list, 
continue with Configuring the Clustered Internet Agent for SSL. 


Configuring the Clustered Internet Agent for SSL 


If you plan to enable SSL, as described in “Securing Internet Agent Connections with SSL” in 
“Internet Agent” in the GroupWise 8 Administration Guide, you must make the SSL certificate file and 
key file available to the Internet Agent in the cluster. The default locations for the SSL certificate file 
and key file are on the cluster nodes along with the GroupWise software, rather than being located 
with the domain and post office on one or more GroupWise partitions. To avoid having multiple 
copies of these files in multiple locations, you should set the locations in ConsoleOne. 


1 On the Internet Agent partition, create the directory where you want to store the certificate and 
key file required for SSL. 
2 Copy the certificate file and key file into the new directory. 


If you need assistance obtaining these files, see “Server Certificates and SSL Encryption” in 
“Security Administration” in the GroupWise 8 Administration Guide. 


3 In ConsoleOne, browse to and select the Domain object. 
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Right-click the Internet Agent object, then click Properties. 

Click GroupWise > SSL Settings. 

In the Certificate File field, browse to and select the certificate file. 
In the SSL Key File field, browse to and select the key file. 

Click OK. 


Continue with Configuring the Internet Agent Cluster Resource to Load and Unload the 
Internet Agent and Its MTA. 


Oo ON OO oO Ff 


Configuring the Internet Agent Cluster Resource to Load and Unload the Internet 
Agent and Its MTA 


The properties of the Cluster Resource object define how the Internet Agent partition functions 
within the cluster, how the Internet Agent is loaded and unloaded, and how failover and failback 
situations are handled. Complete the following tasks for the Internet Agent cluster resource: 

e “Modifying the Cluster Resource Load Script for the Internet Agent and Its MTA” on page 162 

e “Modifying the Cluster Resource Unload Script for the Internet Agent and Its MTA” on page 165 

¢ “Setting the Failover List and Policies for the Internet Agent and Its MTA” on page 167 


Modifying the Cluster Resource Load Script for the Internet Agent and Its MTA 
The cluster resource load script executes whenever the Internet Agent cluster resource comes online. 
To set up the load script in iManager: 


1 Expand Clusters, then click Cluster Options. 


2 Inthe Cluster field, browse to the Cluster object where the Internet Agent cluster resource is 
located. 


3 Click the Cluster object to display the cluster resources that belong to the cluster. 


4 Select the Internet Agent cluster resource that you created when you set up the Internet Agent 
partition, then click Details. 


5 Click Scripts > Load Script. 
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6 (Conditional) If this is an NSS volume or a shared pool, use a load script similar to the following 
example, depending on the configuration of your cluster and nodes: 


#!/bin/bash 
/opt/novell/ncs/lib/nesfuncs 


# mount filesystem 
exit_on_error ncpcon mount /opt="noatime,nodiratime" volume_name=volume_ID 


# add IP address 
exit_on_error add_secondary ipaddress gwia_partition_ip address 


# start service 
exit_on_error /etc/init.d/grpwise start domain 
exit_on_error /etc/init.d/grpwise start domain.gwia 


6a Inthe mount filesystem section, specify the volume name and volume ID of the GWIA 
partition that you are clustering (System Clustering Worksheet item 5): 


6b In the add IP address section, specify the secondary IP address of the GWIA partition 
(System Clustering Worksheet item 7) 


6c Inthe start service section, provide the commands to start the MTA first, following by 
the GWIA. 


7 (Conditional) If this is a traditional Linux volume, use a load script similar to the following 
example, depending on the configuration of your cluster and nodes: 


#! /bin/bash 
/opt/novell/nes/lib/ncsfunc 


# define IP address 
RESOURCE IP=gwia_partition_ip address 


# define filesystem type 
MOUNT_FS=filesystem 


# define device (if using EVMS) 

exit _on_error evms -f /var/opt/novell/ncs/ContainerActivate -rl 
Share ‘uname -n*‘ 
MOUNT_DEV=/dev/evms/Share/dat 


# define mount point 
MOUNT_POINT=/mnt/mount_point directory 


# mount filesystem 
exit_on_error mount -t SMOUNT_FS SMOUNT_DEV SMOUNT_POINT -o noatime,nodiratime 


# add IP address 
exit_on_error add_secondary_ipaddress SRESOURCE_IP 


# start service 
exit_on_error /etc/init.d/grpwise start domain 
exit _on_error /etc/init.d/grpwise start domain.gwia 





exit 0 


7a Inthe define IP address section, specify the secondary IP address of the GWIA partition 
(Internet Agent Clustering Worksheet item 1). 


7b Inthe define filesystem type section, specify the filesystem type that is in use in use on 
the nodes in the cluster (System Clustering Worksheet item 5). 


7c Inthe define mount point section, specify the mount point directory in use for the nodes 
in the cluster (System Clustering Worksheet item 5). 


7d Inthe start service section, provide the commands to start the MTA first, following by 
the GWIA. 


Implementing the Internet Agent in a Linux Cluster 163 


164 


8 If this is an NSS volume or a shared pool, make the following changes to set up the Internet 
Agent load script: 


8a 


8b 
8c 


8d 


8e 


As needed, in the mount command, change reiserfs to whatever file system type is in use 
on nodes in the cluster. 


In the mount command, change vol to the actual device name in use on nodes in the cluster. 


In the mount command, change /mnt /generic to the mount point directory in use on nodes 
in the cluster. 


In the add_secondary_ipaddress command, change a.b.c.d to the secondary IP address 
of the Internet Agent partition (Internet Agent Clustering Worksheet item 1) 


In the start service command, change myservice start to the command to start the 
Internet Agent and its MTA. 


/etc/init.d/grpwise start domain 
/etc/init.d/grpwise start domain.gwia 


9 If this is a traditional Linux volume, use the following load script: 


H! 


/bin/bash 


/opt/novell/ncs/lib/ncsfunc 


# define the IP address 
RESOURCE IP=123.123.1. 


# define the file system type 
MOUNT_FS=reiserf 


# define the device 


exi 


t_on_error evms -f /var/opt/novell/ncs/ContainerActivate -rl 
Share ‘uname -n` 


MOUNT_DEV=/dev/evms/Share/dat 


# define the mount point 
MOUNT_POINT=/mnt/mount_point 


# mount the file system 


exi 


t_on error mount -t SMOUNT_FS SMOUNT_DEV SMOUNT_POINT 


# add the IP address 


exi 





t_on_error add_secondary_ipaddress SRESOURCE_IP 


/etc/init.d/grpwise start domain 
/etc/init.d/grpwise start domain.gwia 


exit 0 


Make the following changes to set up the load script for the Internet Agent: 


9a 


9b 


9c 


9d 


9e 


On the RESOURCE_IP line, change 123.123.1.1 to the secondary IP address of the 
GroupWise partition (Internet Agent Clustering Worksheet item 1). 


As needed on the MOUNT_FS line, change reiserfs to whatever file system type is in use on 
nodes in the cluster. 


On the MOUNT_DEV line, change /dev/evms/Share/dat to the actual device name in use on 
nodes in the cluster. 


On the MOUNT_POINT line, change /mnt/mount_point to the mount point directory in use 
on nodes in the cluster. 


If you created a domain on the partition, use the following command to start the MTA: 


/etc/init.d/grpwise start domain 
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9f Use the following commands to start the Internet Agent and its MTA: 


/etc/init.d/grpwise start domain 
/etc/init.d/grpwise start domain.gwia 


10 Click OK to save the load script. 


Modifying the Cluster Resource Unload Script for the Internet Agent and Its MTA 


The cluster resource unload script executes whenever the Internet Agent cluster resource goes offline. 
Programs should be unloaded in the reverse order of how they were loaded. This ensures that 
supporting programs are not unloaded before programs that rely on them in order to function 


properly. 


1 On the Cluster Resource Properties page of the Internet Agent cluster resource, click Scripts > 
Unload Script. 


2 If this isan NSS volume or a shared pool, use an unload script similar to the following example, 
depending on the configuration of your cluster and nodes: 


#!/bin/bash 
/opt/novell/ncs/lib/ncsfuncs 


# request service stop 
ignore error /etc/init.d/grpwise stop domain.gwia 
ignore error /etc/init.d/grpwise stop domain 


# stop service otherwise 

sleep 8 

ignore error pkill -fx "/opt/novell/groupwise/agents/bin/gwia 
@/media/nss/volume_name/groupwise/agents/share/gwia.cfg" 

ignore error pkill -fx "/opt/novell/groupwise/agents/bin/gwmta 
@/media/nss/volume_name/groupwise/agents/share/domain_name.mta" 


# delete IP address 
ignore error del secondary _ipaddress gwia_partition_ip address 


# unmount filesystem 
exit_on_error umount /mnt/mount_point_directory 


# return status 
exit 0 


2a Inthe request service stop section, provide the commands to stop the GWIA first, 
followed by the MTA. 


2b Inthe stop service otherwise section, adjust the sleep command as needed so that the 
agents can shut down normally on your system without being inadvertently killed by the 
pkill command the follows. 


2c Inthe delete IP address section, specify the secondary IP address of the GWIA partition. 


2d Inthe unmount filesystem section, specify the mount point directory in use for the nodes 
in the cluster. 


2e (Conditional) If you are running the GroupWise High Availability service (gwha), stop it 
before the script stops the agents, then start it again at the end of the unload script. 


This prevents the GroupWise High Availability service from trying to restart the agents 
while the script is trying to stop them. 


Add the following section before the commands to stop the agents: 
# Temporarily disable the gwha service under xinetd 


ignore error /sbin/chkconfig -s gwha off 
ignore error kill -HUP “pidof xinetd~ 
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Add the following section before the return status section: 


# Restart the gwha service under xinetd 
ignore error /sbin/chkconfig -s gwha on 
ignore error kill -HUP “pidof xinetd~ 


3 If this is a traditional Linux volume, use an unload script similar to the following example, 
depending on the configuration of your cluster and nodes: 


#!/bin/bash 
/opt/novell/ncs/lib/ncsfuncs 


# request service stop 
ignore error /etc/init.d/grpwise stop domain.gwia 
ignore error /etc/init.d/grpwise stop domain 


# stop service otherwise 
sleep 8 
ignore error pkill -fx "/opt/novell/groupwise/agents/bin/gwia 


@/media/nss/volume_name/groupwise/agents/share/gwia.cfg" 


ignore _error pkill -fx "/opt/novell/groupwise/agents/bin/gwmta 


@/media/nss/volume_name/groupwise/agents/share/domain_name.mta" 


# define IP address 
RESOURCE IP=gwia_partition_ip address 


# define mount point 
MOUNT_POINT=/mnt/mount_point_ directory 


# delete IP address 
ignore_error del _secondary_ipaddress SRESOURCE_IP 





# unmount filesystem 
exit_on_error umount SMOUNT_POINT 


# return status 
exit 0 


3a Inthe request service stop section, provide the commands to stop the GWIA first, 


3b 


3c 
3d 


3e 


followed by the MTA. 


In the stop service otherwise section, adjust the sleep command as needed so that the 
agents can shut down normally on your system without being inadvertently killed by the 
pkill command the follows. 


In the define IP address section, specify the secondary IP address of the GWIA partition. 


In the define mount point section, specify the mount point directory in use for the nodes 
in the cluster. 


(Conditional) If you are running the GroupWise High Availability (gwha) service, stop it 
before the script stops the agents, then start it again at the end of the unload script. 


This prevents the GroupWise High Availability service from trying to restart the agents 
while the script is trying to stop them. 


Add the following section before the request service stop section: 


# Temporarily disable the gwha service under xinetd 
ignore error /sbin/chkconfig -s gwha off 
ignore error kill -HUP “pidof xinetd~ 


Add the following section before the return status section: 


# Restart the gwha service under xinetd 
ignore error /sbin/chkconfig -s gwha on 
ignore error kill -HUP “pidof xinetd~ 


4 Click OK to save the unload script. 
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Setting the Failover List and Policies for the Internet Agent and Its MTA 


1 On the Cluster Resource Properties page of the Internet Agent cluster resource, click General. 
The default policy settings are often appropriate. By default, a cluster resource: 
¢ Fails over automatically if the node it is running on fails 
¢ Starts automatically on the next node in its failover list 


¢ Continues running at its failover location, even after its most preferred node is again 
available 


If you are considering changing these defaults, see the OES 11 Novell Cluster Services 2 for 
Linux Administration Guide (http://www.novell.com/documentation/oes11/clus_admin_lx/ 
data/h4hgu4hs.html). 


2 Under Preferred Nodes, arrange the nodes in the cluster into the desired failover list for the 
Internet Agent (Internet Agent Clustering Worksheet item 3). 


3 Click OK. 


Enabling Internet Addressing for Your Clustered GroupWise System 


Setting up Internet addressing for a clustered Internet Agent is no different from setting it up for an 
Internet Agent in any other environment. Follow the instructions in “Configuring Internet 
Addressing” in “Internet Agent” in the GroupWise 8 Administration Guide, then return to this point. 


Forcing Use of the Internet Agent Secondary IP Address 


If you want the Internet Agent to send outgoing messages on its secondary IP address, rather than 
using the default of its primary IP address: 
1 Click GroupWise > Network Address. 


2 Inthe TCP/IP Address field, provide the secondary IP address (Internet Agent Clustering 
Worksheet item 1) for the Internet Agent to use for sending outgoing messages. 


3 Select Bind Exclusively to TCP/IP Address. 
4 Click OK. 
5 Continue with Verifying Internet Agent Object Properties. 


Verifying Internet Agent Object Properties 


During installation of the Internet Agent, the Internet Agent object should have been configured 
correctly. However, it can be helpful to verify certain cluster-specific information in order to 
familiarize yourself with the configuration of a clustered Internet Agent. 

+ “Accessing Internet Agent Object Properties” on page 168 

¢ “Verifying the Reference to the Internet Agent Cluster Resource” on page 168 

+ “Verifying the Reference to the Mount Point Directory” on page 168 

¢ “Verifying Post Office Links” on page 168 
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Accessing Internet Agent Object Properties 


1 In ConsoleOne, browse to and select the Internet Agent domain in order to display its contents. 
2 Right-click the Internet Agent object, then click Properties. 


3 Continue with Verifying the Reference to the Internet Agent Cluster Resource. 


Verifying the Reference to the Internet Agent Cluster Resource 
In the Internet Agent object properties pages: 


1 Click SMTP/MIME > Settings. 
2 Verify the contents of the Hostname/DNS “A Record” Name field. 


It displays the hostname as currently configured in DNS. It should display the hostname that 
corresponds to the secondary IP address of the Internet Agent cluster resource. For more 
information, see Section 15.1.5, “Preparing DNS for the Clustered Internet Agent,” on page 155. 


3 Make changes if necessary. 


4 Continue with Verifying the Reference to the Mount Point Directory. 


Verifying the Reference to the Mount Point Directory 
In the Internet Agent object properties pages: 
1 Click Server Directories. 
2 Verify that the displayed directories match the mount point directory and the domain directory. 


3 Make changes if necessary. 
4 Continue with Verifying Post Office Links. 


Verifying Post Office Links 
In the Internet Agent object properties pages: 


1 Click Post Office Links. 


2 Verify that the Access Mode column displays C/S (for client/server mode) for all post offices 
serviced by the Internet Agent. 


3 Verify that the Links column displays the secondary IP addresses of the GroupWise partitions 
where post offices reside, not the IP addresses of any nodes in the cluster. 


4 Make changes if necessary. 


5 Continue with Forcing Use of the Internet Agent Secondary IP Address. 


Testing the Internet Agent in a Linux Cluster 


After you have configured the Internet Agent cluster resource, you can test the load and unload 
scripts by bringing the cluster resource online and taking it offline again. 


1 IniManager, expand Clusters, then click Cluster Manager. 
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The new Internet Agent cluster resource shows Offline in the State column. 


Click the new Internet Agent cluster resource, then click Online. 


a ASE N 
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Select the cluster node where you want to online the Internet Agent cluster resource, then click 


OK. 
After a moment, the Internet Agent cluster resource displays Running in the State column. 


At the server where the Internet Agent is starting, use the following command to see that the 
Internet Agent has started: 


/etc/init.d/grpwise status domain.gwia 


Select the new Internet Agent cluster resource, then click Offline. 


The State column for the Internet Agent cluster resource returns to Offline. 


Use the same command that you used in Step 4 to verify that the Internet Agent has stopped. 
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7 Repeat Step 2 whenever you are ready to bring the new Internet Agent cluster resource online 
permanently. 


8 Continue with Managing Your Clustered GroupWise System. 


15.4 Managing the Internet Agent in a Linux Cluster 


After you have installed the Internet Agent in a cluster, you should consider some long-term 
management issues. 
+ Section 15.4.1, “Updating GroupWise Objects with Cluster-Specific Descriptions,” on page 170 
+ Section 15.4.2, “Knowing What to Expect in an Internet Agent Failover Situation,” on page 171 


15.4.1 Updating GroupWise Objects with Cluster-Specific Descriptions 


After installing the Internet Agent in your clustered GroupWise system, while the cluster-specific 
information is fresh in your mind, you should record the cluster-specific information as part of the 
GroupWise objects in ConsoleOne so that you can easily refer to it later. Be sure to update the 
information in the GroupWise objects if the configuration of your system changes. 


+ “Recording Cluster-Specific Information about the Internet Agent Domain and Its MTA” on 
page 170 


+ “Recording Cluster-Specific Information about the Internet Agent” on page 170 


Recording Cluster-Specific Information about the Internet Agent Domain and Its 
MTA 


To permanently record important cluster-specific information for the Internet Agent domain: 


1 In ConsoleOne, browse to and right-click the Domain object, then click Properties. 


2 Inthe Description field of the Internet Agent domain Identification page, provide a cluster- 
specific description of the Internet Agent domain, including the secondary IP address of its 
GroupWise partition. 


Click OK to save the Internet Agent domain description. 
Select the Internet Agent Domain object to display its contents. 
Right-click the MTA object, then click Properties. 


In the Description field of the MTA Identification page, record the secondary IP address of the 
GroupWise partition. 


on Aà WwW 


This information appears on the MTA console, no matter which node in the cluster it is currently 
running on. 


7 Click OK to save the MTA description. 


8 Continue with Recording Cluster-Specific Information about the Internet Agent. 


Recording Cluster-Specific Information about the Internet Agent 


With the contents of the Internet Agent domain still displayed: 


1 Right-click the Internet Agent object, then click Properties. 
2 Click GroupWise, then click Identification. 
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15.5 


3 Inthe Description field, record the secondary IP address of the GroupWise partition where the 
Internet Agent domain is located. 


This information appears on the Internet Agent console, no matter which node in the cluster it is 


currently running on. 


4 Click OK to save the Internet Agent information. 


5 Continue with Knowing What to Expect in an Internet Agent Failover Situation. 


Knowing What to Expect in an Internet Agent Failover Situation 


The failover behavior of the MTA for the Internet Agent domain is the same as for an MTA ina 


regular domain. See Section 14.6.2, “Knowing What to Expect in MTA and POA Failover Situations,” 


on page 150. 


Failover of the Internet Agent itself is more complex. The various clients (POP3, IMAP4, and LDAP) 
receive an error message that the node is not available. Most of the clients do not attempt to reconnect 


automatically, so the user must exit the client and restart it to reestablish the connection after the 


failover process is complete. Fortunately, the Internet Agent restarts quickly in its failover location so 


users can reconnect quickly. 


As with the MTA and the POA, migration of the Internet Agent takes longer than failover. In fact, the 
Internet Agent can seem especially slow to shut down properly as it finishes its normal processing 
and stops its threads. For a busy Internet Agent, you might need to wait several minutes for it to shut 


down properly. 


Internet Agent Clustering Worksheet 


Item 


1) GroupWise Partition for the 
Internet Agent: 


Secondary IP Address: 
2) Internet Agent 
Domain Name: 


Domain Database Location: 


3) Internet Agent 
Failover List: 


4) Cluster Resource Mount Point: 


Explanation 


Specify the GroupWise partition where the Internet Agent domain will 
be created, along with its secondary IP address. 


For more information, see Section 15.1.2, “Selecting the Internet 
Agent Partition and Secondary IP Address,” on page 154. 


Specify a unique name for the Internet Agent domain. Specify the 
directory on the GroupWise partition where you want to create the 
new domain. 


For more information, see Section 15.1.1, “Planning a Domain for the 
Internet Agent,” on page 154. 


List other nodes in the cluster where the Internet Agent and its MTA 
could fail over. 


For more information, see Section 15.1.3, “Determining an 
Appropriate Failover List for the Internet Agent,” on page 155. 


Specify the mount point directory where the Internet Agent domain will 
be mounted. 


For more information, see Section 15.1.4, “Determining Cluster 
Resource Information for the Internet Agent,” on page 155. 
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Item Explanation 
5) MTA Network Information: Record the MTA network address information that you will need as 
you install the MTA. 
+ MTA IP address 
* MTA i For more information, see Section 15.1.7, “Planning the MTA 
message transfer port Installation,” on page 156. 
+ MTA live remote port 
+ MTA HTTP port 
6) Internet Agent Record the Internet Agent network address information that you will 
Network Information: need to install the Internet Agent. 


+ 


+ 


o 


Internet Agent IP address For more information, see Section 15.1.8, “Planning the Internet 


Agent Installation,” on page 156. 
Internet Agent HTTP port 


Internet Agent Quick Checklist 


Plan the new clustered Internet Agent, including the new domain required to house the Internet 
Agent in a clustering environment. 


See Section 15.1, “Planning the Internet Agent in a Linux Cluster,” on page 153. 

Make sure DNS includes the secondary IP address of the Internet Agent partition 

See Section 15.1.5, “Preparing DNS for the Clustered Internet Agent,” on page 155 

Make sure your firewall is configured to accommodate the Internet Agent. 

See Section 15.1.6, “Preparing Your Firewall for the Clustered Internet Agent,” on page 155. 
Create the new Internet Agent domain. 

See Section 15.2.1, “Creating a Domain for the Internet Agent,” on page 157. 

Set up the MTA for the new Internet Agent domain. 

See Section 15.2.2, “Installing the MTA for the Internet Agent Domain,” on page 157. 
Install the Internet Agent. 

See “Installing and Setting Up the Internet Agent Software in Your Cluster” on page 158. 
Modify the Internet Agent cluster resource load script. 


See “Modifying the Cluster Resource Load Script for the Internet Agent and Its MTA” on 
page 162. 


Modify the Internet Agent cluster resource unload script. 


See “Modifying the Cluster Resource Unload Script for the Internet Agent and Its MTA” on 
page 165. 


Set up the Internet Agent failover list and policies. 

See “Setting the Failover List and Policies for the Internet Agent and Its MTA” on page 167. 
Enable Internet Addressing for the clustered Internet Agent. 

See “Enabling Internet Addressing for Your Clustered GroupWise System” on page 167. 
Double-check the cluster-specific Internet Agent object properties. 


See “Verifying Internet Agent Object Properties” on page 167. 
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O Test the clustered Internet Agent. 
See Section 15.3, “Testing the Internet Agent in a Linux Cluster,” on page 168. 


O Record cluster-specific information in the properties pages of the GroupWise objects associated 
with the Internet Agent. 


See Section 15.4.1, “Updating GroupWise Objects with Cluster-Specific Descriptions,” on 
page 170. 
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16.1 


Implementing WebAccess in a Linux 
Cluster 


You should already have set up at least a basic GroupWise system, as described in Chapter 13, 
“Planning GroupWise in a Linux Cluster,” on page 121 and Chapter 14, “Setting Up a Domain and a 
Post Office in a Linux Cluster,” on page 131. As part of this process, you filled out the “System 
Clustering Worksheet” on page 128. If you do not have access to the filled-out worksheet, print the 
worksheet now and fill in the clustering information as it currently exists on your system. You need 
this information as you implement the WebAccess Agent in a cluster. 

+ Section 16.1, “Understanding the WebAccess Components,” on page 175 

* Section 16.2, “Planning the WebAccess Agent in a Linux Cluster,” on page 176 

+ Section 16.3, “Setting Up the WebAccess Agent in a Linux Cluster,” on page 178 

+ Section 16.4, “Testing the WebAccess Agent in a Linux Cluster,” on page 189 

¢ Section 16.5, “Managing the WebAccess Agent in a Linux Cluster,” on page 190 

+ Section 16.6, “WebAccess Agent Clustering Worksheet,” on page 191 

+ Section 16.7, “WebAccess Agent Quick Checklist,” on page 192 


Understanding the WebAccess Components 


If you are not familiar with GroupWise WebAccess, review “GroupWise WebAccess Overview” in 
“Installing GroupWise WebAccess” in the GroupWise 8 Installation Guide. 


As you plan WebAccess in a clustering environment, you must keep in mind that you will plan and 
set up two WebAccess components: 


+ WebAccess Agent (gwinter) that will be associated with a domain in your GroupWise system 


e WebAccess Application (a Java servlet) that will be added to your Web server (Apache). The 
WebAccess Application is currently not supported on a cluster resource. 


You install the WebAccess Agent on each node in the cluster. You install the WebAccess Application 
to your Web server, which must not be clustered. This means that the WebAccess client login to the 
Web server at the following URL: 


http://secondary_IP_address/gw/webacc 


is available only when the Web server is running. 
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16.2.1 


Planning the WebAccess Agent in a Linux Cluster 


In a cluster, you need to create a separate domain to house each GroupWise gateway, including the 
WebAccess Agent. 


Section 16.6, “WebAccess Agent Clustering Worksheet,” on page 191 lists the information you need 
as you set up the WebAccess Agent in a clustering environment. You should print the worksheet and 
fill it out as you complete the tasks listed below: 

* Section 16.2.1, “Planning a Domain for the WebAccess Agent,” on page 176 


¢ Section 16.2.2, “Selecting the WebAccess Agent Partition and Secondary IP Address,” on 
page 177 


¢ Section 16.2.3, “Determining an Appropriate Failover List for the WebAccess Agent,” on 
page 177 


¢ Section 16.2.4, “Determining Cluster Resource Information for the WebAccess Agent,” on 
page 177 


¢ Section 16.2.5, “Planning the MTA Installation,” on page 178 
è Section 16.2.6, “Planning the WebAccess Agent Installation,” on page 178 
è Section 16.2.7, “Planning the WebAccess Application Installation,” on page 178 


Planning a Domain for the WebAccess Agent 


The considerations involved in planning a domain for the WebAccess Agent are much the same as 
planning any other domain. In preparation, review “Planning a New Domain”, then print and fill out 
the “Domain Worksheet” in “Domains” in the GroupWise 8 Administration Guide. 


Keep in mind the following cluster-specific details: 


+ When you specify the location for the domain directory on the Domain Worksheet, remember 
that it is on a GroupWise partition, not on the node where you running the GroupWise 
Installation program. This location is referred to as the WebAccess Agent partition because it is 
where the WebAccess Agent message queues are located. 


+ Do not concern yourself with the GroupWise agent information on the Domain Worksheet. You 
can stop with item 10. You will plan the MTA installation later. 


When you have completed the Domain Worksheet, transfer the key information from the Domain 
Worksheet to the WebAccess Agent Clustering Worksheet. 


WEBACCESS AGENT CLUSTERING WORKSHEET 


Under Item 1: GroupWise Partition for the WebAccess Agent, transfer the domain location to the 
WebAccess Agent Clustering Worksheet. 


Under Item 2: WebAccess Agent Domain Name, transfer the domain name and database directory to 
the WebAccess Agent Clustering Worksheet. 





IMPORTANT: Do not create the new domain until you are instructed to do so in Section 16.3.1, 
“Creating a Domain for the WebAccess Agent,” on page 178. 
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16.2.2 


16.2.3 


16.2.4 


Selecting the WebAccess Agent Partition and Secondary IP Address 


As with the MTA and the POA, the WebAccess Agent needs a secondary IP address that remains the 
same no matter which node in the cluster it is running on. You can place the WebAccess Agent and its 
domain on a GroupWise partition where a domain or post office already reside, which means that the 
WebAccess Agent shares the same secondary IP address as that domain or post office and fails over 
along with that domain or post office. Or you can place the WebAccess Agent and its domain on its 
own GroupWise partition, which means that it has its own secondary IP address and fails over 
independently. 


WEBACCESS AGENT CLUSTERING WORKSHEET 


Under Item 1: GroupWise Partition for WebAccess Agent, specify the secondary IP address for the 
WebAccess Agent partition. 


Under Item 5: MTA Network Information, copy the same secondary IP address. 


Under Item 6: WebAccess Agent Network Information, copy the same secondary IP address. 


Determining an Appropriate Failover List for the WebAccess Agent 


By default, a GroupWise partition is configured to have all nodes in the cluster in its failover list, 
organized in ascending alphanumeric order. Only one node at a time can have a particular 
GroupWise partition mounted and active. If a GroupWise partition’s preferred node fails, the 
partition fails over to the next node in the failover list. You should customize the failover list for each 
GroupWise partition based on the fan-out-failover principle. 


As with the MTA and the POA, you need to decide which nodes in the cluster are appropriate 
locations for the WebAccess Agent partition to fail over to. You must install the WebAccess Agent 
software on all of the nodes where you want the WebAccess Agent to be able to fail over. For a review 
of failover lists, see Section 13.6.2, “Determining Appropriate Failover Lists for the Agents,” on 

page 126, which describes the issues in the context of planning MTA and POA installations. 


WEBACCESS AGENT CLUSTERING WORKSHEET 


Under Item 3: WebAccess Agent Failover List, list the nodes that you want in the WebAccess Agent 
partition failover list. 


Determining Cluster Resource Information for the WebAccess Agent 


A cluster resource is a shared partition, secondary IP address, application, service, Web server, etc., 
that can function successfully anywhere in the cluster. Cluster resources include the GroupWise 
agents and the Messenger agents. When using the Configure GroupWise for Clustering option, the 
GroupWise Installation program needs to know the mount point for the GroupWise partition where 
the WebAccess Agent domain is located. 


WEBACCESS AGENT CLUSTERING WORKSHEET 


Under Item 4: Cluster Resource Mount Point, list the mount point for the GroupWise partition where the 
WebAccess Agent domain is located. 
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16.2.5 


16.2.6 


16.2.7 


16.3 


16.3.1 


Planning the MTA Installation 


Follow the instructions in Section 13.6.4, “Planning the Linux Agent Installation,” on page 127, then 
return to this point. After you follow the instructions, you have a filled-out Agent Clustering 
Worksheet to use when you install the MTA. 





IMPORTANT: Do not install the Linux MTA until you are instructed to do so in Section 16.3, “Setting 
Up the WebAccess Agent in a Linux Cluster,” on page 178. 





Planning the WebAccess Agent Installation 


Aside from the cluster-specific issues discussed in the preceding sections, the considerations 
involved in planning to install the WebAccess Agent are the same in a clustering environment as for 
any other environment. Review the installation instructions in “Installing the Linux WebAccess 
Agent” in “Installing GroupWise WebAccess” in the GroupWise 8 Installation Guide. Use the 
“GroupWise WebAccess Installation Summary Sheets” to record the planning information you will 
need as you install the WebAccess Agent in your cluster. 


IMPORTANT: Do not install the WebAccess Agent software until you are instructed to do so in 
Setting Up the WebAccess Agent in a Linux Cluster. 





Planning the WebAccess Application Installation 


The WebAccess Application must be installed on a non-clustered Web server. For WebAccess 
Application planning information, see “Determining the WebAccess and WebPublisher Applications’ 
Configuration” in “Installing GroupWise WebAccess” in the GroupWise 8 Installation Guide. 


Setting Up the WebAccess Agent in a Linux Cluster 


You should already have reviewed Section 16.2, “Planning the WebAccess Agent in a Linux Cluster,” 
on page 176 and filled out Section 16.6, “WebAccess Agent Clustering Worksheet,” on page 191. You 
are now ready to complete the following tasks to set up the WebAccess Agent in a clustering 
environment: 

+ Section 16.3.1, “Creating a Domain for the WebAccess Agent,” on page 178 

è Section 16.3.2, “Installing the MTA for the WebAccess Agent Domain,” on page 179 

è Section 16.3.3, “Installing and Configuring the WebAccess Agent in a Cluster,” on page 179 


è Section 16.3.4, “Installing and Configuring the WebAccess Application in a Cluster,” on page 189 


Creating a Domain for the WebAccess Agent 


The WebAccess Agent domain will be a secondary domain. To create it, follow the instructions in 
Section 14.2, “Creating a New Secondary Domain in a Linux Cluster,” on page 132, taking your 
information from the WebAccess Agent Clustering Worksheet, rather than the System Clustering 
Worksheet, then return to this point. 


Do not create any post offices in the WebAccess Agent domain. 


After you have created the domain, continue with Installing the MTA for the WebAccess Agent 
Domain. 
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16.3.2 Installing the MTA for the WebAccess Agent Domain 


The MTA for the WebAccess Agent domain can be installed just like any other MTA in your clustered 
GroupWise system. Follow the instructions in Section 14.4.1, “Installing and Setting Up the Agents in 
Your Cluster,” on page 134, then return to this point. 


You do not need to edit the MTA startup file. You do not need to modify the Cluster Resource object 
properties until after you have installed the WebAccess Agent. 


After you have installed the MTA, continue with Installing and Configuring the WebAccess Agent in 
a Cluster. 


16.3.3 Installing and Configuring the WebAccess Agent in a Cluster 


After you have created a domain for the WebAccess Agent and installed the MTA for that domain, 
you are ready to install and configure the WebAccess Agent. 

¢ “Installing and Setting Up the WebAccess Agent Software in Your Cluster” on page 179 

+ “Configuring Clustered Logging” on page 182 

¢ “Configuring the Clustered WebAccess Agent for SSL” on page 183 


+ “Configuring the WebAccess Agent Cluster Resource to Load and Unload the WebAccess Agent 
and Its MTA” on page 183 


¢ “Verifying WebAccess Agent Object Properties” on page 188 


Installing and Setting Up the WebAccess Agent Software in Your Cluster 


The WebAccess Agent must be installed on each node in its failover list (WebAccess Agent Clustering 
Worksheet item 3). 

+ “Running the WebAccess Agent Installation Program on the Preferred Node” on page 179 

+ “Running the WebAccess Agent Installation Program on Subsequent Nodes” on page 180 

+ “Testing Your WebAccess Agent Installation on Each Node” on page 182 


Running the WebAccess Agent Installation Program on the Preferred Node 


1 Make sure that the WebAccess Agent software is available in the software distribution directory 
you created in Step 6 in Section 14.1, “Setting Up a New GroupWise System in a Linux Cluster,” 
on page 131. 


2 Mount the WebAccess Agent partition (WebAccess Agent Clustering Worksheet item 1) where 
the WebAccess Agent message queues are located. 


3 From the software distribution directory, start the GroupWise Installation program and select 
Configure GroupWise for Clustering. 





` _ GroupWise ©) " 


Select the language for this installation from the 
choices below. 





English Ad] 


W Configure GroupWise for clustering 
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4 Install the WebAccess Agent software, following the steps provided in “Installing the Linux 
WebAccess Agent” in “Installing GroupWise WebAccess” in the GroupWise 8 Installation Guide. 


5 Configure the WebAccess Agent according to the “GroupWise WebAccess Installation Summary 
Sheets” that you filled out in Section 16.2, “Planning the WebAccess Agent in a Linux Cluster,” 
on page 176, paying special attention to the cluster resource information on the Server 
Information page. 





b _ GroupWise WebAccess Agent Configuration 





[Z introduction Specify the network address of the WebAccess Agent. The IP address or 
DNS host name will be the same as the WebAccess Agent's server. The 
License Agreement port number should be the port you want the WebAccess Agent to listen 
on. 
O Server information 
o Network Address 
m) © IP address: l 
g DNS host name: 
o Port: 7205 
Path to the Cluster Resource mount point: 
(=) 
Cancel | Previous | Next | 


Server Information 

















As a result of selecting Configure GroupWise for Clustering on the preferred node, the following 
cluster-specific configuration actions are performed: 


+ The WebAccess Agent startup file (webac80a.waa) is created in mount_point/groupwise/ 


agents/share on the shared resource so that the WebAccess Agent uses the same startup 
file regardless of which cluster node it is running on. The --home switch includes the mount 
point and the path to the database so that the startup file is valid when mounted to each 
cluster node. 


If this is the first GroupWise agent installed on this cluster node, the GroupWise High 
Availability service is automatically configured and its configuration file (gwha . conf) is 
created in the /etc/opt/novell/groupwise directory. If another GroupWise agent has 
already been installed on this cluster node, the gwha. conf file is updated to include the 
WebAccess Agent. 


The clusterimport.conf file in the gwinst subdirectory of the software distribution 
directory from which you ran the GroupWise Installation program is updated, so that the 
cluster-specific information collected when you configured the WebAccess Agent on the 
preferred node is available when you install the WebAccess Agent on subsequent nodes. 


The WebAccess Agent is not configured to start automatically on system startup. Ina 
cluster, you do not want the WebAccess Agent to start automatically whenever a node 
restarts. 


6 Continue with Running the WebAccess Agent Installation Program on Subsequent Nodes. 


Running the WebAccess Agent Installation Program on Subsequent Nodes 


1 On the next node in the WebAccess Agent failover list, mount the WebAccess Agent partition 
(WebAccess Agent Clustering Worksheet item 1) where the WebAccess Agent message queues 
are located. 


2 From the software distribution directory you created in Step 6 in Section 14.1, “Setting Up a New 
GroupWise System in a Linux Cluster,” on page 131, start the GroupWise Installation program 
and select Configure GroupWise for Clustering. 
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GroupWise ©) 


Select the language for this installation from the 
choices below. 





English hd) 


W Configure GroupWise for clustering 


C] eme | 





Because of the existence of the clusterimport .conf file in the gwinst subdirectory of the 


software distribution directory, a new installation option, Import Clustering Data, is now available 
on the main GroupWise Installation program page. 





Novell. GroupWise» 


View the Readme 


View the Quickstart 


View the Installation Guide 


Create or update a GroupWise system 


Install Products 


Import Clustering Data 


Visit the Novell GroupWise Web Site 





Displays a web paye with important information you should read before installing, 


Displays a high-level checklist of system requirements and installation steps to guide you through setting 
up your GroupWise system. 


Displays overview and task information that will help you plan, install, and update a GroupWise system, 
as well as install additional components such as GroupWise WebAccess and GroupWise Intemet Agent. 


Launches the GroupWise installation and Setup Advisors, These advisors step you through the creation 
of anew GroupWise system orthe updating of an existing GroupWise system. 


Displays the GroupWise components you can individually install once you've created a Groupwise 
system, 


Import custering data from previously configured products, 


Launches your Web browserto display GroupWise information located on the Novell Web site, 
{tttp:/mumnovell.com/ 
products /yroupwise}, 





3 Install the WebAccess Agent software on the cluster node as usual, but do not use the Configure 
option. 


4 On the main page of the Installation program, click Import Clustering Data, then click Next. 





Import Clustering Data 5S x 








Import Data 
ica] Introduction Select the cluster data you would like to import and click Next. 
O import Data 
Oo imple Provo3 - /mntigwsystem 


Marketing - smntigwsystem 
GWIA - Imntigwsystem 
WEBAC7OA - smntigwsystem 


Select all Deselect all 


Cancel 


Previous Next 








All GroupWise agents that you have installed from the software distribution directory are listed, 
based on the information stored in the clusterimport . conf file. 


5 Select the GroupWise agents that you want to configure on the current cluster node, then click 
OK. 
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The Import Clustering Data option performs the following configuration actions for each 
subsequent node where you run it: 


¢ The grpwise script is created in the /etc/init.d directory on the current cluster node. It is 
configured specifically for the agents you just selected. 


+ The GroupWise High Availability service is automatically configured on the current cluster 
node and its configuration file (gwha. conf) is created in the /etc/opt /novell/groupwise 
directory. It is configured specifically for the agents you just selected. 


Because the agent startup files and log files are stored on the shared resource, they do not need 
to be customized for each cluster node. 


6 Repeat Step 1 through Step 5 for each cluster node in the WebAccess Agent failover list. 


After you install and configure the WebAccess Agent on each node in its failover list, the cluster 
node is ready for the WebAccess Agent to fail over to it. 


7 Continue with Testing Your WebAccess Agent Installation on Each Node. 


Testing Your WebAccess Agent Installation on Each Node 


1 Test the WebAccess Agent by starting it with a user interface, as described in “Starting the Linux 
WebAccess Agent” in “Installing GroupWise WebAccess” in the GroupWise 8 Installation Guide. 
/opt/novell/groupwise/agents/bin/gwinter --show @webac80a.waa & 

2 Stop the WebAccess Agent by closing the window that it is running in. 


3 After you can see that the WebAccess Agent stopped successfully, test it by starting it as a 
daemon, as described in “Starting the Linux GroupWise Agents as Daemons” in “Installing 
GroupWise Agents” in the GroupWise 8 Installation Guide. 


/etc/inet.d/grpwise start webac80a 
/etc/inet.d/grpwise status webac80a 


4 Stop the WebAccess Agent. 


/etc/inet.d/grpwise stop webac80a 
/etc/inet.d/grpwise status webac80a 


5 Repeat Step 1 through Step 4for each node in the WebAccess Agent failover list. 
6 Continue with “Configuring Clustered Logging” on page 182 


Configuring Clustered Logging 


The default location for the WebAccess Agent log files is on the cluster nodes along with the 
WebAccess Agent software, rather than being located with the domain on the WebAccess Agent 
partition. To avoid having multiple copies of log files in multiple locations, you should set the 
location in ConsoleOne. 


1 On the WebAccess Agent partition where the domain is located, create the directory where you 
want to store WebAccess Agent log files. 

In ConsoleOne, browse to and select the Domain object. 

Right-click the WebAccess Agent object, then click Properties. 

Click GroupWise > Log Settings. 

In the Log File Path field, browse to and select the directory you created in Step 1, then click OK. 
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If you want the WebAccess Agent to use SSL connections, continue with Configuring the 
Clustered WebAccess Agent for SSL 
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or 


Skip to “Configuring the WebAccess Agent Cluster Resource to Load and Unload the 
WebAccess Agent and Its MTA” on page 183. 


Configuring the Clustered WebAccess Agent for SSL 


If you plan to enable SSL, as described in “Securing WebAccess Agent Connections with SSL” in 
“WebAccess” in the GroupWise 8 Administration Guide, you need to make the SSL certification file and 
key file available to the WebAccess Agent in the cluster. The default locations for the SSL certificate 
file and key file are on the cluster nodes along with the WebAccess Agent software, rather than being 
located with the domain on a GroupWise partition. To avoid having multiple copies of these files in 
multiple locations, you should set the locations in ConsoleOne. 


1 On the WebAccess Agent partition, create the directory where you want to store the certificate 
and key file required for SSL. 
2 Copy the certificate file and key file into the new directory. 


If you need assistance obtaining these files, see “Server Certificates and SSL Encryption” in 
“Security Administration” in the GroupWise 8 Administration Guide. 


In ConsoleOne, browse to and select the Domain object. 
Right-click the WebAccess Agent object, then click Properties. 
Click GroupWise > SSL Settings. 

In the Certificate File field, browse to and select the certificate file. 
In the SSL Key File field, browse to and select the key file. 

Click OK. 


After you have set these locations to the WebAccess Agent partition, continue with Configuring 
the WebAccess Agent Cluster Resource to Load and Unload the WebAccess Agent and Its MTA. 
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Configuring the WebAccess Agent Cluster Resource to Load and Unload the 
WebAccess Agent and Its MTA 


The properties of the Cluster Resource object define how the WebAccess Agent partition functions 
within the cluster, how the WebAccess Agent is loaded and unloaded, and how failover and failback 
situations are handled. Complete the following tasks for the WebAccess Agent cluster resource: 


e “Modifying the Cluster Resource Load Script for the WebAccess Agent and Its MTA” on 
page 183 


e “Modifying the Cluster Resource Unload Script for the WebAccess Agent and Its MTA” on 
page 185 


¢ “Setting the Failover List and Policies for the WebAccess Agent and Its MTA” on page 187 
Modifying the Cluster Resource Load Script for the WebAccess Agent and Its MTA 


The cluster resource load script executes whenever the WebAccess Agent cluster resource comes 
online. 


To set up the load script in iManager: 


1 Expand Clusters, then click Cluster Options. 


2 Inthe Cluster field, browse to the Cluster object where the WebAccess Agent cluster resource is 
located. 
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3 Click the Cluster object to display the cluster resources that belong to the cluster. 


4 Select the WebAccess Agent cluster resource that you created when you set up the WebAccess 
Agent partition, then click Properties. 


The default load script from a generic IP service template appears as follows: 


#!/bin/bash 
/opt/novell/nces/lib/nesfuncs 


# mount the file system 
exit_on_error mount -t reiserfs /dev/evms/vol /mnt/generic 


# add the IP address 
exit_on error add_secondary_ipaddress a.b.c.d 


# start the service 
exit_on_error /etc/init.d/myservice start 


# return status 
exit 0 





5 If this is an NSS volume or a shared pool, make the following changes to set up the WebAccess 
Agent load script: 


5a As needed, in the mount command, change reiserfs to whatever file system type is in use 
on nodes in the cluster. 


5b In the mount command, change vol to the actual device name in use on nodes in the cluster. 


5c In the mount command, change /mnt/generic to the mount point directory in use on nodes 
in the cluster. 


5d In the add_secondary_ipaddress command, change a.b.c.d to the secondary IP address 
of the WebAccess Agent partition (WebAccess Agent Clustering Worksheet item 1) 


5e In the start service command, change myservice start to the command to start the 
WebAccess Agent and its MTA. 


/etc/init.d/grpwise start domain 
/etc/init.d/grpwise start webac80a 


6 If this is a traditional Linux volume, use the following load script: 
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#! /bin/bash 
/opt/novell/nces/lib/ncsfunce 


# define the IP address 
RESOURCE IP=123.123.1. 


# define the file system type 
MOUNT_FS=reiserf 


# define the device 

exit _on_error evms -f /var/opt/novell/ncs/ContainerActivate -rl 
Share ‘uname -n'` 
MOUNT_DEV=/dev/evms/Share/dat 


# define the mount point 
MOUNT_POINT=/mnt/mount_point 


# mount the file system 
exit_on_error mount -t SMOUNT_FS SMOUNT_DEV SMOUNT_POINT 


# add the IP address 
exit_on_error add_secondary_ipaddress SRESOURCE_IP 





/etc/init.d/grpwise start domain 
/etc/init.d/grpwise start domain.webac80a 


exit 0 


Make the following changes to set up the load script for the agents: 


6a On the RESOURCE_IP line, change 123.123.1.1 to the secondary IP address of the 
GroupWise partition (WebAccess Agent Clustering Worksheet item 1) 


6b As needed on the MOUNT_FS line, change reiserfs to whatever file system type is in use on 


nodes in the cluster. 


6c On the MOUNT_DEV line, change /dev/evms/Share/dat to the actual device name in use on 


nodes in the cluster. 


6d On the MOUNT_POINT line, change /mnt/mount_point to the mount point directory in use 


on nodes in the cluster. 


6e Use the following command to start the MTA: 


/etc/init.d/grpwise start domain 


6f Use the following command to start the WebAccess Agent: 


/etc/init.d/grpwise start domain.webac80a. 


7 Click OK to save the load script. 


Modifying the Cluster Resource Unload Script for the WebAccess Agent and Its MTA 


The cluster resource unload script executes whenever the WebAccess Agent cluster resource goes 


offline. Programs should be unloaded in the reverse order of how they were loaded. This ensures that 


supporting programs are not unloaded before programs that rely on them in order to function 
properly. 


1 On the Cluster Resource Properties page of the WebAccess Agent cluster resource, click Scripts > 


Unload Script. 


The default unload script appears as follows: 
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#!/bin/bash 
/opt/novell/ncs/lib/ncsfuncs 


# request service stop 
ignore error /etc/init.d/myservice stop 


# stop service otherwise 
sleep 8 
ignore error fuser -k /mnt/generic 


# del the IP address 
ignore_error del_secondary_ipaddress a.b.c.d 


# umount the file system 
exit_on_error umount /mnt/generic 


# return status 
exit 0 


2 If this is an NSS volume or a shared pool, make the following changes: 


2a 


2b 


2c 


2d 


2e 


In the request service stop section, change myservice stop to the command to stop 
the WebAccess Agent and its MTA. 


/etc/init.d/grpwise stop webac80a 
/etc/init.d/grpwise stop domain 


In the stop service otherwise section (used if the agents do not stop normally), remove 


these commands: 


sleep 8 
ignore error fuser -k /mnt/generic 


Use these commands instead to stop the WebAccess Agent and its MTA: 


ignore error /etc/init.d/grpwise stop webac80a 
ignore error /etc/init.d/grpwise stop domain 


sleep 8 


ignore error pkill -fx "/opt/novell/groupwise/agents/bin/gwinter 
@/webac80a.waa" 

ignore error pkill -fx "/opt/novell/groupwise/agents/bin/gwmta 
@/path_to_startup_file/domain.mta" 


In the del IP address section, change a.b.c.d to the secondary IP address used in the 
load script. 


In the umount file system section, change /mnt/generic to the mount point directory 
used in the load script. 


3 If this is a traditional Linux volume, use the following unload script: 
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#!/bin/bash 
/opt/novell/nes/lib/nesfuncs 


/etc/init.d/grpwise stop domain.webac80a 
/etc/init.d/grpwise stop domain 


# define the IP address 
RESOURCE IP=172.16.5.18 


# define the mount point 
MOUNT_POINT=/mnt/mount_point 


sleep 8 
ignore_error fuser -k SMOUNT_POINT 


# del IP the address 
ignore_error del _secondary_ipaddress SRESOURCE_IP 


# umount the file system 
exit_on_error umount SMOUNT_POINT 


# return status 
exit 0 


Make the following changes to set up the unload script for the agents. 
3a Use the following command to stop the WebAccess Agent: 


/etc/init.d/grpwise stop domain.webac80a 


3b Use the following command to stop the MTA: 
/etc/init.d/grpwise stop domain 


3c On the RESOURCE_IP line, change 172.16.5.18 to the secondary IP address used in the 
load script. 


3d On the MOUNT_POINT line, change /mnt /mount_point to the mount point directory used in 
the load script. 


3e Adjust the sleep command as needed so that the agents can shut down normally on your 
system without being inadvertently killed. by the fuser -k command that follows. 


3f Inthe fuser -k command (used if the agents do not stop normally), change -k to -mk. 
The -m parameter obtains the PID numbers of the processes to kill. 
4 Click OK to save the unload script. 


Setting the Failover List and Policies for the WebAccess Agent and Its MTA 


1 On the Cluster Resource Properties page of the WebAccess Agent cluster resource, click General. 
The default policy settings are often appropriate. By default, a cluster resource: 
¢ Fails over automatically if the node it is running on fails 
¢ Starts automatically on the next node in its failover list 


¢ Continues running at its failover location, even after its most preferred node is again 
available 


If you are considering changing these defaults, see the OES 11 Novell Cluster Services 2 for 
Linux Administration Guide (http://www.novell.com/documentation/oes11/clus_admin_lx/ 
data/h4hgu4hs.html) . 
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2 Under Preferred Nodes, arrange the nodes in the cluster into the desired failover list for the 
WebAccess Agent (WebAccess Agent Clustering Worksheet item 3). 


3 Click OK. 


Verifying WebAccess Agent Object Properties 


During installation of the WebAccess Agent, the WebAccess Agent object should have been 
configured correctly. However, it can be helpful to verify certain cluster-specific information in order 
to familiarize yourself with the configuration of a clustered WebAccess Agent. 

e “Accessing WebAccess Agent Object Properties” on page 188 

¢ “Verifying Post Office Links” on page 188 

¢ “Forcing Use of the Web Access Agent Secondary IP Address” on page 188 


Accessing WebAccess Agent Object Properties 
1 In ConsoleOne, browse to and select the WebAccess Agent domain in order to display its 
contents. 
2 Right-click the WebAccess Agent object, then click Properties. 
3 Continue with Verifying Post Office Links. 


Verifying Post Office Links 
In the WebAccess object properties pages: 


1 Click Post Office Links. 


2 Verify that the Access Mode column displays C/S (for client/server mode) for all post offices 
serviced by the WebAccess Agent. 


3 Verify that the Links column displays the secondary IP addresses of the GroupWise partitions 
where post offices reside, not the IP addresses of any nodes in the cluster. 


4 Make changes if necessary. 


5 Continue with Forcing Use of the Web Access Agent Secondary IP Address. 


Forcing Use of the Web Access Agent Secondary IP Address 


If you want the WebAccess Agent to always use its secondary IP address, rather than using the 
primary IP address: 
1 Click GroupWise > Network Address. 


2 Inthe TCP/IP Address field, provide the secondary IP address (WebAccess Agent Clustering 
Worksheet item 1) for the Internet Agent. 


3 Select Bind Exclusively to TCP/IP Address. 
4 Click OK. 
5 Continue with Testing the WebAccess Agent in a Linux Cluster. 
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16.3.4 
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Installing and Configuring the WebAccess Application in a Cluster 


If you have clustered your Web server, you must install the WebAccess Application on each node 
where the Web server is installed, as described in “Installing the WebAccess Application and 
WebPublisher Application” in “Installing GroupWise WebAccess” in the GroupWise 8 Installation 
Guide. 


Testing the WebAccess Agent in a Linux Cluster 


After you have configured the WebAccess Agent cluster resource, you can test the load and unload 


scripts by bringing the cluster resource online and taking it offline again. 


1 IniManager, expand Clusters, then click Cluster Manager. 









Unrestricted Access 


A] Roles and Tasks 
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The new WebAccess Agent cluster resource shows Offline in the State column. 


2 Click the new WebAccess Agent cluster resource, then click Online. 





DM Ae N 


@ Roles and Tasks 


fall Categories ~] 


Clusters > Cluster Manager > Online 





Archive Versioning =| Resource: Mesa 
E Clusters Select the cluster node where you want the resource to load. 
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16.5 


16.5.1 


3 Select the cluster node where you want to online the WebAccess Agent cluster resource, then 
click OK. 


After a moment, the WebAccess Agent cluster resource displays Running in the State column. 
4 At the server where the WebAccess Agent is starting, use the following command to see that the 
Internet Agent has started: 
/etc/init.d/grpwise status webac80a 
5 Select the new WebAccess Agent cluster resource, then click Offline. 
The State column for the WebAccess Agent cluster resource returns to Offline. 
6 Use the same command that you used in Step 4 to verify that the WebAccess Agent has stopped. 


7 Repeat Step 2 whenever you are ready to bring the new Internet Agent cluster resource online 
permanently. 


8 Continue with Managing the WebAccess Agent in a Linux Cluster. 


Managing the WebAccess Agent in a Linux Cluster 


After you have installed the WebAccess Agent in a cluster, you should consider some long-term 
management issues. 

¢ Section 16.5.1, “Updating GroupWise Objects with Cluster-Specific Descriptions,” on page 190 

+ Section 16.5.2, “Knowing What to Expect ina WebAccess Agent Failover Situation,” on page 191 


Updating GroupWise Objects with Cluster-Specific Descriptions 


After installing the WebAccess Agent in your clustered GroupWise system, while the cluster-specific 
information is fresh in your mind, you should record the cluster-specific information as part of the 
GroupWise objects in ConsoleOne so that you can easily refer to it later. Be sure to update the 
information in the GroupWise objects if the configuration of your system changes. 


¢ “Recording Cluster-Specific Information about the WebAccess Agent Domain and Its MTA” on 
page 190 
+ “Recording Cluster-Specific Information about the WebAccess Agent” on page 191 


Recording Cluster-Specific Information about the WebAccess Agent Domain and 
Its MTA 


To permanently record important cluster-specific information for the WebAccess Agent domain: 


1 In ConsoleOne, browse to and right-click the Domain object, then click Properties. 


2 Inthe Description field of the WebAccess Agent domain Identification page, provide a cluster- 
specific description of the WebAccess Agent domain, including the secondary IP address of its 
GroupWise partition. 


Click OK to save the WebAccess Agent domain description. 
Select the Internet Agent Domain object to display its contents. 
Right-click the MTA object, then click Properties. 


In the Description field of the MTA Identification page, record the secondary IP address of the 
GroupWise partition. 
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16.5.2 


16.6 


This information appears on the MTA console, no matter which node in the cluster it is currently 
running on. 


7 Click OK to save the MTA description. 


8 Continue with Recording Cluster-Specific Information about the WebAccess Agent. 


Recording Cluster-Specific Information about the WebAccess Agent 


With the contents of the WebAccess Agent domain still displayed: 


1 Right-click the WebAccess Agent object, then click Properties. 
2 Click GroupWise, then click Identification. 


3 Inthe Description field, record the secondary IP address of the GroupWise partition where the 
WebAccess Agent domain is located. 


This information appears on the WebAccess Agent console, no matter which node in the cluster 
it is currently running on. 


4 Click OK to save the WebAccess Agent information. 


5 Continue with Knowing What to Expect in an Internet Agent Failover Situation. 


Knowing What to Expect in a WebAccess Agent Failover Situation 


The failover behavior of the MTA for the WebAccess Agent domain is the same as for an MTA ina 
regular domain. See Section 14.6.2, “Knowing What to Expect in MTA and POA Failover Situations,” 
on page 150. 


When the WebAccess Agent fails over, the WebAccess client user sees the following message: 


Unable to communicate with the GroupWise WebAccess Agent 


The user just needs to be patient. When the WebAccess Agent comes up on the next node, the user 
can continue working without logging in again. 


If the POA for the user’s post office fails over, the WebAccess client becomes unresponsive, but there 
is no error message. Again, the user should be patient until the POA comes up on the next node. 
Then the user can continue working without logging in again. 


As with the MTA and the POA, migration of the WebAccess Agent takes longer than failover. In fact, 
the WebAccess Agent can seem especially slow to shut down properly as it finishes its normal 
processing, stops its threads, and stops the Document Viewer Agent. For a busy WebAccess Agent, 
you might need to wait several minutes for it to shut down properly. 


WebAccess Agent Clustering Worksheet 


Item Explanation 


1) GroupWise Partition for the Specify the GroupWise partition where the WebAccess Agent domain 
WebAccess Agent: will be created, along with its secondary IP address. 


Secondary IP Address: For more information, see Section 16.2.2, “Selecting the WebAccess 
Agent Partition and Secondary IP Address,” on page 177. 
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Item Explanation 

2) WebAccess Agent Specify a unique name for the Internet Agent domain. Specify the 

Domain Name: directory on the GroupWise partition where you want to create the 
new domain. 


Domain Database Location: 


For more information, see Section 16.2.1, “Planning a Domain for the 
WebAccess Agent,” on page 176. 


3) WebAccess Agent List other nodes in the cluster where the WebAccess Agent and its 
Failover List: MTA could fail over. 


For more information, see Section 16.2.3, “Determining an 
Appropriate Failover List for the WebAccess Agent,” on page 177. 


4) Cluster Resource Mount Point: Specify the mount point directory where the WebAccess Agent 


domain will be mounted. 


For more information, see Section 16.2.4, “Determining Cluster 
Resource Information for the WebAccess Agent,” on page 177. 


5) MTA Network Information: Record the MTA network address information that you will need as 


+ 


+ 


you install the MTA. 
MTA IP address 
i For more information, see Section 16.2.5, “Planning the MTA 
MTA message transfer port Installation,” on page 178. 
MTA live remote port 


MTA HTTP port 


6) WebAccess Agent Record the WebAccess Agent network address information that you 
Network Information: will need to install the WebAccess Agent. 
+ WebAccess Agent IP For more information, see Section 16.2.6, “Planning the WebAccess 
address Agent Installation,” on page 178. 


+ 


WebAccess Agent HTTP 
port 


WebAccess Agent Quick Checklist 


o 


Plan the new clustered WebAccess Agent, including the new domain required to house the 
WebAccess Agent in a clustering environment. 


See Section 16.2, “Planning the WebAccess Agent in a Linux Cluster,” on page 176. 

Create the new WebAccess Agent domain. 

See Section 16.3.1, “Creating a Domain for the WebAccess Agent,” on page 178. 

Set up the MTA for the new WebAccess Agent domain. 

See Section 16.3.2, “Installing the MTA for the WebAccess Agent Domain,” on page 179. 

Install the WebAccess Agent. 

See Section 16.3.3, “Installing and Configuring the WebAccess Agent in a Cluster,” on page 179. 
Modify the WebAccess Agent cluster resource load script. 


See “Modifying the Cluster Resource Load Script for the WebAccess Agent and Its MTA” on 
page 183. 


Modify the WebAccess Agent cluster resource unload script. 
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See “Modifying the Cluster Resource Unload Script for the WebAccess Agent and Its MTA” on 
page 185. 


Set up the WebAccess Agent failover list and policies. 

See “Setting the Failover List and Policies for the WebAccess Agent and Its MTA” on page 187. 
Double-check the cluster-specific WebAccess Agent object properties. 

See “Verifying WebAccess Agent Object Properties” on page 188. 

Test the clustered WebAccess Agent. 

See Section 16.4, “Testing the WebAccess Agent in a Linux Cluster,” on page 189. 


Record cluster-specific information in the properties pages of the GroupWise objects associated 
with the WebAccess Agent. 


See Section 16.5.1, “Updating GroupWise Objects with Cluster-Specific Descriptions,” on 
page 190. 
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17.1 


Implementing GroupWise Monitor ina 
Linux Cluster 


You should already have set up at least a basic GroupWise system, as described in Chapter 13, 
“Planning GroupWise in a Linux Cluster,” on page 121 and Chapter 14, “Setting Up a Domain and a 
Post Office in a Linux Cluster,” on page 131. As part of this process, Section 13.7.1, “System 
Clustering Worksheet,” on page 128 was filled out. If you do not have access to the filled-out 
worksheet, print the worksheet now and fill in the clustering and network address information as it 
currently exists on your system. You need this information as you implement Monitor in a cluster. 

+ Section 17.1, “Understanding the Monitor Components,” on page 195 

+ Section 17.2, “Planning GroupWise Monitor in a Linux Cluster,” on page 196 

+ Section 17.3, “Setting Up GroupWise Monitor in a Linux Cluster,” on page 198 

¢ Section 17.4, “Testing the Monitor Agent in a Linux Cluster,” on page 205 

+ Section 17.5, “Managing the Monitor Agent in a Linux Cluster,” on page 206 

+ Section 17.6, “Monitor Agent Clustering Worksheet,” on page 206 

è Section 17.7, “Monitor Agent Quick Checklist,” on page 207 


Understanding the Monitor Components 


If you are not familiar with GroupWise Monitor, review “GroupWise Monitor Overview” in 
“Installing GroupWise Monitor” in the GroupWise 8 Installation Guide. 


As you plan Monitor in a clustering environment, you must keep in mind that you will plan and set 
up two Monitor components: 


¢ Monitor Agent (gwmon) that will be associated with a domain in your GroupWise system 


è Monitor Application (a Java servlet) that will be added to your Web server (Apache). You must 
install the Monitor Application on a non-clustered Web server. 


You install the Monitor Agent on each node in the cluster. You install the Monitor Application to your 
Web server, which must not be clustered. This means that the Monitor Agent Web console at the 
following URL is always available, because it is part of the cluster: 


http: //secondary_IP_address :8200 


However, the Monitor Web console at the following URLs are not available if the Web server is down: 
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17.2 


17.2.1 


17.2.2 


Table 17-1 Monitor Web Console URLs 


NetWare or http://Web_server_address/gw/gwmonitor 
Windows 
Web Server: 


Linux http://Web_server_address/gwmon/gwmonitor 
Web Server: 


Planning GroupWise Monitor in a Linux Cluster 


A major system configuration difference between the Monitor Agent and other GroupWise agents is 
that the Monitor Agent needs access to a domain during installation but does not need permanent 
access to a domain thereafter. 


Section 17.6, “Monitor Agent Clustering Worksheet,” on page 206 lists information you need as you 
set up Monitor in a clustering environment. You should print the worksheet and fill it out as you 
complete the planning tasks listed below 

+ Section 17.2.1, “Selecting a Domain for Access during Monitor Agent Installation,” on page 196 


¢ Section 17.2.2, “Selecting an MTA for the Monitor Agent to Access after Installation,” on 
page 196 


+ Section 17.2.3, “Selecting the Monitor Agent Partition and Secondary IP Address,” on page 197 
è Section 17.2.4, “Determining an Appropriate Failover List for the Monitor Agent,” on page 197 
è Section 17.2.5, “Determining Cluster Resource Information for the Monitor Agent,” on page 197 


¢ Section 17.2.6, “Planning the Monitor Agent Installation,” on page 197 


Selecting a Domain for Access during Monitor Agent Installation 


During installation, the Monitor Agent Installation program needs access to a domain database 
(wpdomain. db) in order to obtain information about agents to monitor. You might want to use the 
domain you created for use with the Internet Agent, as described in Section 15.2.1, “Creating a 
Domain for the Internet Agent,” on page 157, although you can use any domain in your GroupWise 
system. 


MONITOR CLUSTERING WORKSHEET 


Under Item 2: Domain Name, specify the domain and domain directory that the Monitor Agent 
Installation program can use to obtain information about your GroupWlse system. 


Selecting an MTA for the Monitor Agent to Access after Installation 


After installation, you can configure the Monitor Agent to be independent of a domain database. To 
do this, you configure the Monitor Agent to communicate with an MTA by way of TCP/IP. 


MONITOR CLUSTERING WORKSHEET 


Under Item 3: MTA IP Address, specify the MTA IP address and message transfer port that the 
Monitor Agent can use after installation to communicate with an MTA to obtain agent information. 
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17.2.3 


17.2.4 


17.2.5 


17.2.6 


Selecting the Monitor Agent Partition and Secondary IP Address 


As with the MTA and the POA, the Monitor Agent needs a secondary IP address that remains the 
same no matter which node in the cluster it is running on. You can associate the Monitor Agent with 
the domain that was accessed during installation or with any other domain, so that they fail over 
together, or you can associate the Monitor Agent with its own shared partition, so that it fails over 
independently of any domain. 


MONITOR CLUSTERING WORKSHEET 


Under Item 1: GroupWise Partition for Monitor Agent, specify the secondary IP address for the 
Monitor Agent. 


Determining an Appropriate Failover List for the Monitor Agent 


By default, a GroupWise partition is configured to have all nodes in the cluster in its failover list, 
organized in ascending alphanumeric order. Only one node at a time can have a particular 
GroupWise partition mounted and active. If a GroupWise partition’s preferred node fails, the 
partition fails over to the next node in the failover list. You should customize the failover list for each 
GroupWise partition based on the fan-out-failover principle. 


As with the other agents, you need to decide which nodes in the cluster would be appropriate 
locations for the Monitor Agent to fail over to. You must install the Monitor Agent software on all of 
the nodes where you want the Monitor Agent to be able to fail over. For a review of failover lists, see 
Section 13.6.2, “Determining Appropriate Failover Lists for the Agents,” on page 126, which 
describes the issues in the context of planning MTA and POA installations. 


MONITOR CLUSTERING WORKSHEET 


Under Item 4: Monitor Agent Failover List, list the nodes that you want in the Monitor Agent failover list. 


Determining Cluster Resource Information for the Monitor Agent 


A cluster resource is a shared partition, secondary IP address, application, service, Web server, etc., 
that can function successfully anywhere in the cluster. Cluster resources include the GroupWise 
agents and the Messenger agents. When using the Configure GroupWise for Clustering option, the 
GroupWise Installation program needs to know the mount point for the GroupWise partition where 
it can access a domain database in order to gather information about agents to monitor. The 
Installation program also needs to know the secondary IP address of the GroupWise partition. 


MONITOR AGENT CLUSTERING WORKSHEET 


Under Item 5: Cluster Resource Information, list the mount point and secondary IP address for the 
GroupWise partition where the domain and post office will be located. 


Planning the Monitor Agent Installation 


Aside from the cluster-specific issues discussed in the preceding sections, the considerations 
involved in planning to install the Monitor Agent are the same in a clustering environment as for any 
other environment. Review the installation instructions in “Installing the Linux Monitor Agent” in 
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“Installing GroupWise Monitor” in the GroupWise 8 Installation Guide. Use the “GroupWise Monitor 
Installation Summary Sheets” to record the types of planning information you need as you install the 
Monitor Agent in your cluster. 





IMPORTANT: Do not install the Monitor Agent software until you are instructed to do so in 
Section 17.3, “Setting Up GroupWise Monitor in a Linux Cluster,” on page 198. 





17.3 Setting Up GroupWise Monitor in a Linux Cluster 


GroupWise Monitor depends on a Web server, Apache in particular on Linux. However, Apache is 
not typically installed in a cluster and the Monitor Application is not supported in a cluster. 
Therefore, these instructions do not include that task. 


è Section 17.3.1, “Installing and Configuring the Monitor Agent on Each Node in Your Cluster,” 
on page 198 


¢ Section 17.3.2, “Configuring the Monitor Agent Cluster Resource to Load and Unload the 
Monitor Agent,” on page 200 


17.3.1 Installing and Configuring the Monitor Agent on Each Node in Your 


198 


Cluster 


The Monitor Agent must be installed on each node in the Monitor Agent failover list (Monitor Agent 
Clustering Worksheet item 4). The Monitor Application is installed to your Web server and is 
therefore not installed on nodes in the cluster. 

¢ “Running the Monitor Installation Program on the Preferred Node” on page 198 

e “Running the Monitor Agent Installation Program on Subsequent Nodes” on page 199 

+ “Configuring the Monitor Agent Web Console for SSL” on page 200 

¢ “Testing the Monitor Agent Installation on Each Node” on page 200 


Running the Monitor Installation Program on the Preferred Node 


1 Make sure that the Monitor Agent software is available in the software distribution directory 
you created in Step 6 in Section 14.1, “Setting Up a New GroupWise System in a Linux Cluster,” 
on page 131. 


2 Mount the GroupWise partition (Monitor Agent Clustering Worksheet item 2) where the 
Monitor Agent Installation program can access a domain database. 


3 From the software distribution directory, start the Installation program and select Configure 
GroupWise for Clustering. 


“GroupWise (sss iN ES 


Select the language for this installation from the 
choices below. 





{English “y| 


W Configure GroupWise for clustering 





4 Install the Monitor Agent software, following the steps provided in “Installing the Linux 
Monitor Agent” in “Installing GroupWise Monitor” in the GroupWise 8 Installation Guide. 
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5 Configure the Monitor Agent, following the steps provided in “Configuring the Linux Monitor 
Agent” in “Installing GroupWise Monitor” in the GroupWise 8 Installation Guide, paying special 
attention to the cluster resource information on the System Options page. 


h _ GroupWise Monitor Agent Configuration ©) ie. 


System Options 
[K] introduction The Monitor Agent can monitor GroupWise and GroupWise Messenger 
systems. Which systems do you want to monitor? 
[Z] License Agreement 
CO System Options 


m 


WE GroupWise 


J GroupWise Messenger 


Path to the Cluster Resource mount point 





| e) 
IP address of the cluster resource: 


Cancel Previous Next 








As a result of selecting Configure GroupWise for Clustering on the preferred node, the following 
cluster-specific configuration actions are performed: 


¢ The Monitor Agent configuration file (monitor.xml) is created in mount_point/groupwise/ 
agents/share on the shared resource so that the Monitor Agent uses the same 
configuration file regardless of which cluster node it is running on. The HOME_PATH 
option includes the mount point and the path to the database so that the configuration file 
is valid when mounted to each cluster node. 


+ The --log startup switch in the grpwise-ma script is set to a location on the shared resource 
(mount_point/groupwise/agents/log) so that Monitor Agent logging information is 
written to the same log file regardless of which cluster node it is running on. Gateway 
accounting files that you can use to generate reports are stored in the acct subdirectory of 
this location. 


+ The Monitor Agent is not configured to start automatically on system startup. In a cluster, 
you do not want the Monitor Agent to start automatically whenever a node restarts. 


6 Continue with Running the Monitor Agent Installation Program on Subsequent Nodes 


Running the Monitor Agent Installation Program on Subsequent Nodes 


1 On the next node in the Monitor Agent failover list, mount the GroupWise partition (Monitor 
Agent Clustering Worksheet item 2) where the Monitor Agent Installation program can access a 
domain database. 


2 From the software distribution directory you created in Step 6 in Section 14.1, “Setting Up a New 
GroupWise System in a Linux Cluster,” on page 131, start the GroupWise Installation program 
and select Configure GroupWise for Clustering. 





` _ GroupWise ©) | 


Select the language for this installation from the 
choices below. 





|English xj 


w Configure GroupWise for clustering 


cana 
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3 Install the Monitor Agent software on the cluster node as usual, but do not use the Configure 
option. 


For the Monitor Agent, you do not need to import clustering data on subsequent nodes as you 
do for the other GroupWise agents. 


4 Repeat Step 1 through Step 3 for each cluster node in the Monitor Agent failover list. 


After you install the Monitor Agent on each node in its failover list, the cluster node is ready for 
the Monitor Agent to fail over to it. 


5 Continue with Configuring the Monitor Agent Web Console for SSL. 


Configuring the Monitor Agent Web Console for SSL 


If you plan to secure the Monitor Web console using SSL, you need to provide an SSL certificate file. 
You can place the file on the Monitor Agent partition, rather than each node. 


1 Create a directory on the Monitor Agent partition where you want to store the certificate file. 


2 Inthe grpwise-ma script, use the --httpcertfile switch to specify the full path to the directory you 
created in Step 1. 


Continue with Testing the Monitor Agent Installation on Each Node. 


Testing the Monitor Agent Installation on Each Node 


1 Test the Monitor by starting it as a daemon, as described in “Starting the Linux Monitor Agent as 
a Daemon” in “Installing GroupWise Monitor” in the GroupWise 8 Installation Guide. 


/etc/initd/grpwise-ma start 
/etc/initd/grpwise-ma status 


2 Then stop the Monitor Agent. 


/etc/initd/grpwise-ma stop 
/etc/initd/grpwise-ma status 


3 Return to “Running the Monitor Installation Program on the Preferred Node” on page 198 for 
each node in the Monitor Agent failover list (Monitor Agent Clustering Worksheet item 4) 


When you have installed the Monitor Agent on all of the nodes in the Monitor Agent fail over list, 
continue with Configuring the Monitor Agent Cluster Resource to Load and Unload the Monitor 
Agent. 


Configuring the Monitor Agent Cluster Resource to Load and Unload 
the Monitor Agent 
The properties of the Monitor Agent Cluster Resource object define how the Monitor Agent functions 


within the cluster, how the Monitor Agent is loaded and unloaded, and how failover and failback 
situations are handled. Complete the following tasks for the Monitor Agent cluster resource: 


e “Modifying the Cluster Resource Load Script for the Monitor Agent” on page 201 
e “Modifying the Cluster Resource Unload Script for the Monitor Agent” on page 202 
¢ “Setting the Failover List and Policies for the Monitor Agent” on page 204 
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Modifying the Cluster Resource Load Script for the Monitor Agent 


The cluster resource load script executes whenever the Monitor Agent cluster resource comes online. 
To set up the load script in iManager: 


1 Expand Clusters, then click Cluster Options. 


2 Inthe Cluster field, browse to the Cluster object where the Monitor Agent cluster resource is 
located. 


3 Click the Cluster object to display the cluster resources that belong to the cluster. 


4 Select the Monitor Agent cluster resource that you created when you set up the Monitor Agent 
partition, then click Properties. 


The default load script from a generic IP service template appears as follows: 


#!/bin/bash 
/opt/novell/nces/lib/nesfuncs 


# mount the file system 
exit _on_error mount -t reiserfs /dev/evms/vol /mnt/generic 


# add the IP address 
exit_on_error add_secondary_ipaddress a.b.c.d 


# start the service 
exit_on_error /etc/init.d/myservice start 


# return status 
exit 0 





5 If this is an NSS volume or a shared pool, make the following changes to set up the Monitor 
Agent load script: 


5a As needed, in the mount command, change reiserfs to whatever file system type is in use 
on nodes in the cluster. 


5b In the mount command, change vol to the actual device name of the device in use on nodes 
in the cluster. 


5c In the mount command, change /mnt/generic to the mount point directory in use on nodes 
in the cluster. 


5d In the add_secondary_ipaddress command, change a.b.c.d to the secondary IP address 
of the Monitor Agent cluster resource (Monitor Agent Clustering Worksheet item 1) 


5e In the start service command, change myservice start to the command to start the 
Monitor Agent. 


/etc/init.d/grpwise-ma start 


6 If this is a traditional Linux volume, use the following load script: 
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#! 


/bin/bash 


/opt/novell/ncs/lib/ncsfunc 


# define the IP address 
RESOURCE IP=123.123.1. 


# define the file system type 
MOUNT_FS=reiserf 


# define the device 


exi 


t_on_error evms -f /var/opt/novell/ncs/ContainerActivate -rl 
Share ‘uname -n` 


MOUNT_DEV=/dev/evms/Share/dat 


# define the mount point 
MOUNT_POINT=/mnt/mount_point 


# mount the file system 


exi 


t_on error mount -t SMOUNT_FS SMOUNT_DEV SMOUNT_POINT 


# add the IP address 


exi 


t_on error add_secondary_ipaddress SRESOURCE_IP 


/etc/init.d/grpwise-ma start 


exit 





0 


Make the following changes to set up the load script for the Monitor Agent: 


6a 


6b 


6c 


6d 


6e 


On the RESOURCE_IP line, change 123.123.1.1 to the secondary IP address of the 
GroupWise partition (Monitor Agent Clustering Worksheet item 1). 


As needed, on the MOUNT_FS line, change reiserfs to whatever file system type is in use on 
nodes in the cluster. 


On the MOUNT_DEV line, change /dev/evms/Share/dat to the actual device name in use on 
nodes in the cluster. 


On the MOUNT_POINT line, change /mnt/mount_point to the mount point directory in use 
on nodes in the cluster. 


Use the following command to start the Monitor Agent: 


/etc/init.d/grpwise-ma start 


7 Click OK to save the load script. 


Modifying the Cluster Resource Unload Script for the Monitor Agent 


The cluster resource unload script executes whenever the Monitor Agent cluster resource goes 


offline. 


1 On the Cluster Resource Properties page of the Monitor Agent cluster resource, click Scripts > 
Unload Script. 


The default unload script appears as follows: 
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#!/bin/bash 
/opt/novell/ncs/lib/ncsfuncs 


# request service stop 
ignore error /etc/init.d/myservice stop 


# stop service otherwise 
sleep 8 
ignore error fuser -k /mnt/generic 


# del the IP address 
ignore_error del_secondary_ipaddress a.b.c.d 


# umount the file system 
exit_on_error umount /mnt/generic 


# return status 
exit 0 


2 If this is an NSS volume or a shared pool, make the following changes: 
2a Inthe request service stop section, change myservice stop to the command to stop 
the Monitor Agent. 
/etc/init.d/grpwise-ma stop 
2b Inthe stop service otherwise section (used if the agents do not stop normally), remove 


these commands: 


sleep 8 
ignore error fuser -k /mnt/generic 


2c Use these commands instead: 


ignore error /etc/init.d/grpwise-ma stop 
sleep 8 
ignore error pkill -fx "/opt/novell/groupwise/agents/bin/gwmon 
--home /domain_directory" 


2d Inthe del IP address section, change a.b.c.d to the secondary IP address used in the 
load script. 


2e Inthe umount file system section, change /mnt/generic to the mount point directory 
used in the load script. 


3 If this is a traditional Linux volume, use the following unload script: 
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#!/bin/bash 
. /opt/novell/ncs/lib/ncesfuncs 


/etc/init.d/grpwise-ma stop 


# define the IP address 
RESOURCE IP=172.16.5.18 


# define the mount point 
MOUNT_POINT=/mnt/mount_point 


sleep 8 
ignore_error fuser -k SMOUNT_POINT 


# del the IP address 
ignore_error del _secondary_ipaddress SRESOURCE_IP 


# umount the file system 
exit_on_error umount SMOUNT_POINT 


# return status 
exit 0 


Make the following changes to set up the unload script for the Monitor Agent. 


3a Use the following command to stop the Monitor Agent: 
/etc/init.d/grpwise-ma stop 


3b On the RESOURCE_IP line, change 172.16.5.18 to the secondary IP address used in the 
load script. 


3c On the MOUNT_POINT line, change /mnt/mount_point to the mount point directory used in 
the load script. 


3d Adjust the sleep command as needed so that the Monitor Agent can shut down normally 
on your system without being inadvertently killed. by the fuser -k command that follows. 


3e Inthe fuser -k command (used if the Monitor Agent does not stop normally), change -k 
to -mk. 


The -m parameter obtains the PID numbers of the processes to kill. 
4 Click OK to save the unload script. 


Setting the Failover List and Policies for the Monitor Agent 


1 On the Cluster Resource Properties page of the Monitor Agent cluster resource, click General. 
The default policy settings are often appropriate. By default, a cluster resource: 
¢ Fails over automatically if the node it is running on fails 
¢ Starts automatically on the next node in its failover list 


¢ Continues running at its failover location, even after its most preferred node is again 
available 


If you are considering changing these defaults, see the OES 11 Novell Cluster Services 2 for 
Linux Administration Guide (http://www.novell.com/documentation/oes11/clus_admin_lx/ 
data/h4hgu4hs.html). 


2 Under Preferred Nodes, arrange the nodes in the cluster into the desired failover list for the 
Monitor Agent (Monitor Agent Clustering Worksheet item 4). 


3 Click OK. 
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17.4 Testing the Monitor Agent in a Linux Cluster 


After you have configured the Monitor Agent cluster resource, you can test the load and unload 
scripts by bringing the Monitor Agent cluster resource online and taking it offline again. 


1 IniManager, expand Clusters, then click Cluster Manager. 





ADMIN — 
Unrestricted Access g a E | [| A N 


@ Roles and Tasks 


All Categories z] 


Clusters » Cluster Manager 


Archive Versioning =! Cluster Manager 
E Clusters View or change cluster server and resource status. 


Cluster Manager 
Cluster Event Lo: Cluster: |qw-clusterlx.servers.novell El 
Cluster Options Run Report 

eDirectory Administration 


eDirectory Maintenance Epoch: 1 


File Access (NetStorage) B & 
File Protocols 











gw-5 gw-7 

Groups 
Help Desk Cluster State View 
iFolder Management Online | Offline | Migrate | Respond to Alert 
iPrint m Type Name ~ State ~ Location Lives Up Since 

Prnt X 
LDAP & Master_IP_Address_Resource ® me gw-5 1 ty 2 eae 
Linux User Management re E ® ss 9 Jul 5, 2005 
NMAS Running 3:04:19 PM 
Novell Certificate Access T & Le Offline d 
Novell Certificate Server Update Update Interval...| 
Partition and Replica Management e 
Fl Paceworde 3J aes | 





The new Monitor Agent cluster resource shows Offline in the State column. 


2 Click the new Monitor Agent cluster resource, then click Online. 





@ Roles and Tasks 


fall Categories ~] 


Clusters > Cluster Manager > Online 





Archive Versioning =| Resource: Mesa 
E Clusters Select the cluster node where you want the resource to load. 


Cluster Manager 
Cluster Event Log 
Cluster Options 


State: =) Offline 


eDirectory Administration Online Node Target: 
eDirectory Maintenance w5 


File Access (NetStorage) 
File Protocols 


3 Select the cluster node where you want to online the Monitor Agent cluster resource, then click 
OK. 


After a moment, the Monitor Agent cluster resource displays Running in the State column. 


4 At the server where the Monitor Agent is starting, use the following command to see that the 
Monitor Agent has started: 


/etc/init.d/grpwise-ma status 
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5 Select the new Monitor Agent cluster resource, then click Offline. 
The State column for the Monitor Agent cluster resource returns to Offline. 
6 Use the same command that you used in Step 4 to verify that the Monitor Agent has stopped. 


7 Repeat Step 2 whenever you are ready to bring the new Monitor Agent cluster resource online 
permanently. 


8 Continue with Managing the Monitor Agent in a Linux Cluster. 


17.5 Managing the Monitor Agent in a Linux Cluster 


When the Monitor Agent fails over, it must repoll all the monitored agents to ascertain their current 
status. This may take a few moments, depending on the number of agents being monitored. 
However, no action is necessary on your part as the Monitor Agent starts on the next node in the 
cluster. 
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206 


Item Explanation 

1) GroupWise Partition for Specify the name of the Cluster Resource object for the Monitor 
Monitor Agent: Agent, along with its secondary IP address. 

Secondary IP Address: For more information, see Section 17.2.3, “Selecting the Monitor 


Agent Partition and Secondary IP Address,” on page 197. 


2) GroupWise Partition for Specify a GroupWise partition where there is a domain database from 
Domain which the Monitor Agent can gather information about agents to 


: monitor. Also provide the domain name and directory. 
Domain Name: 


oe For more information, see Section 17.2.1, “Selecting a Domain for 
Domain Directory: Access during Monitor Agent Installation,” on page 196. 


3) MTA IP Address: If you want the Monitor Agent to be able to fail over independently, 
specify the IP address and message transfer port number of an MTA 
with which the Monitor Agent can communicate, as an alternative to 
accessing a domain database. 


MTA MTP Port Number: 


For more information, see Section 17.2.2, “Selecting an MTA for the 
Monitor Agent to Access after Installation,” on page 196 


4) Monitor Agent Failover List: List the nodes in the cluster where the Monitor Agent could fail over. 


For more information, see Section 17.2.4, “Determining an 
Appropriate Failover List for the Monitor Agent,” on page 197. 


5) Cluster Resource Information List the cluster resource information for the GroupWise partition 
where the domain is located so that the Monitor Agent can access its 
+ Path to the cluster resource domain database for information about agents to monitor. 
mount point 
For more information see, Section 17.2.5, “Determining Cluster 


* IP address of the cluster Resource Information for the Monitor Agent,” on page 197. 


resource 
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17.7 Monitor Agent Quick Checklist 


C Plan the new clustered Monitor Agent, including a domain to access during installation to 
gather information about agents to monitor 


See Section 17.2, “Planning GroupWise Monitor in a Linux Cluster,” on page 196. 
O Install the Monitor Agent on all nodes in the Monitor Agent’s failover list. 


See Section 17.3.1, “Installing and Configuring the Monitor Agent on Each Node in Your 
Cluster,” on page 198. 


O Modify the Monitor Agent cluster resource load script. 

See “Modifying the Cluster Resource Load Script for the Monitor Agent” on page 201. 
O Modify the Monitor Agent cluster resource unload script. 

See “Modifying the Cluster Resource Unload Script for the Monitor Agent” on page 202. 
C Set up the Monitor Agent failover list and policies. 

See “Setting the Failover List and Policies for the Monitor Agent” on page 204. 
C Test the clustered Monitored Agent. 

See Section 17.4, “Testing the Monitor Agent in a Linux Cluster,” on page 205. 
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Backing Up a GroupWise System ina 
Linux Cluster 


To back up GroupWise data in a Linux cluster, you can use the GroupWise Database Copy (DBCopy) 
utility to copy the data from the live GroupWise system to a static location for backup. For more 
information, see “Backing Up GroupWise Databases” and “GroupWise Database Copy Utility” in 
“Databases” in the GroupWise 8 Administration Guide. 


You can also use the GroupWise Target Service Agent for File Systems (TSAFSGW), as described in 
“GroupWise Target Service Agent” in “Databases” in the GroupWise 8 Administration Guide. 


In a clustering environment, TSAFSGW must be installed and loaded on each node from which your 
backup software backs up any portion of your GroupWise system. To accommodate the variable 
locations of data to back up from a clustered GroupWise system, use the /home startup switch on the 
smsconfig command for every domain and post office on every shared volume that might ever be 
mounted on that node. 


When TSAFSGW runs, it backs up the shared volumes that are currently accessible and skips shared 
volumes that are not currently accessible. If a shared volume migrates, you must restart TSAFSGW so 
that it can re-determine what shared volumes are currently available for backup. 


To restore data in a clustering environment, you must run your backup/restore software on the node 
where the location to restore is currently mounted. 
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Updating a GroupWise System ina 
Linux Cluster 


In a Linux cluster, you must install the GroupWise software on each node in the cluster. Before you 
run the GroupWise Installation program to install updated software, make sure you know all the 
cluster nodes where the GroupWise software is already installed. 


It is very important to update all nodes on the failover list of each domain and post office at the same 
time because each domain and post office should serviced by only one one version of the agent 
software. If you do not update all nodes on the failover list at once, there is the potential for a domain 
or post office to be serviced by a different version of the agent software during a failover situation. 
This can cause database problems. 


Keep in mind these cluster-specific details as you follow the instructions in “Update” in the 
GroupWise 8 Installation Guide to update your GroupWise system in a NetWare cluster. 
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Moving an Existing Linux GroupWise 8 
System into a Linux Cluster 


If you are adding the high availability benefits of Novell Cluster Services to a GroupWise 8 system 
that is already up and running, the first step is to install Novell Cluster Services following the 
instructions in the OES 11 Novell Cluster Services 2 for Linux Administration Guide (http:// 
www.novell.com/documentation/oes11/clus_admin_lx/data/h4hgu4hs.html). You should also review 
Chapter 12, “Introduction to GroupWise 8 and Novell Cluster Services on Linux,” on page 119 to 
help you apply clustering principles and practices to your GroupWise system. 


You do not need to transfer your entire GroupWise system into the cluster all at once. You could 
transfer individual post offices where the needs for high availability are greatest. You could transfer a 
domain and all of its post offices at the same time. You might decide that you don’t need to have all of 
your GroupWise system running in the cluster. 


This section provides a checklist to help you get started with moving your GroupWise system into a 
clustering environment: 


O Decide which shared partitions in your cluster you want to use for GroupWise domains and 
post offices. 


O Decide which nodes in your storage area network you want have on failover lists for the 
GroupWise agents. 


O Review Chapter 13, “Planning GroupWise in a Linux Cluster,” on page 121. Fill out the 
Section 13.7.1, “System Clustering Worksheet,” on page 128 to help you decide which domains 
and post offices you want move to which shared partitions. 


O Move a domain and/or post office onto the GroupWise partition, following the instructions in 
“Moving a Domain” in “Domains” or “Moving a Post Office” in “Post Offices” in the GroupWise 
8 Administration Guide. 


O Review Section 13.6, “Deciding How to Install and Configure the Linux Agents in a Cluster,” on 
page 126, fill out the Section 13.7.2, “Agent Clustering Worksheet,” on page 129, and install the 
agents as needed for the first clustered domain and/or post office, following the instructions in 
Section 14.4, “Installing and Configuring the MTA and the POA in a Cluster,” on page 134. This 
includes setting up the load and unload scripts for the GroupWise partition. 


C Test the first component of your clustered GroupWise system, following the instructions in 
Section 14.5, “Testing Your Clustered GroupWise System,” on page 147. 


C Take care of the cluster management details described in Section 14.6, “Managing Your 
Clustered GroupWise System,” on page 148. 


O Move more domains and post offices into the cluster as needed. If you have GroupWise libraries, 
see Section 13.5, “Planning a New Library for a Clustered Post Office,” on page 125. 


O Add other components to your clustered GroupWise system as needed, following the 
instructions in: 


¢ Chapter 15, “Implementing the Internet Agent in a Linux Cluster,” on page 153 
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¢ Chapter 16, “Implementing WebAccess in a Linux Cluster,” on page 175. 
¢ Chapter 17, “Implementing GroupWise Monitor in a Linux Cluster,” on page 195 
¢ Chapter 18, “Backing Up a GroupWise System in a Linux Cluster,” on page 209 
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Moving a Clustered GroupWise 8 
System from NetWare to Linux 


For general information about moving from a NetWare cluster to a Linux cluster, see the OES 11 
Novell Cluster Services 2 for Linux Administration Guide (http://www.novell.com/documentation/oes11/ 
clus_admin_]x/data/h4hgu4hs.html). It is possible to have a cluster that includes both NetWare and 
Linux servers. Therefore, you can move your GroupWise 8 system from NetWare servers to Linux 
servers one component at a time. However, all of the servers on the failover list of each GroupWise 
component must be of the same platform. For example, a domain and MTA on a NetWare server 
cannot fail over to a Linux server; they must fail over to another NetWare server. 


Ideally, you should administer a GroupWise system on Linux using the Linux version of 
ConsoleOne, which is available from Novell Product Downloads site (http://download.novell.com). 


The GroupWise Server Migration Guide provides instructions to help you move components of your 
GroupWise system to Linux. 


GroupWise 6.5 cannot run in a cluster on Linux. Therefore, if you have a clustered GroupWise 6.5 
system, you must update it to GroupWise 8 before you can move it into a Linux cluster. 
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22.1 


22.1.1 


Implementing Messenger in a Linux 
Cluster 


Novell Messenger does not require the existence of a GroupWise system in the cluster, but 
presumably one has already been set up as described in Chapter 13, “Planning GroupWise in a Linux 
Cluster,” on page 121 and Chapter 14, “Setting Up a Domain and a Post Office in a Linux Cluster,” on 
page 131. As part of the process of setting up GroupWise in the cluster, you filled out the “System 
Clustering Worksheet” on page 128. Some of the information from that worksheet is helpful as you 
implement Messenger in your cluster. 

¢ Section 22.1, “Planning Your Messenger System in a Linux Cluster,” on page 217 

+ Section 22.2, “Setting Up Your Messenger System in a Linux Cluster,” on page 219 

+ Section 22.3, “Testing Your Clustered Messenger System,” on page 227 

+ Section 22.4, “Managing Your Clustered Messenger System,” on page 228 

+ Section 22.5, “Messenger Clustering Worksheet,” on page 228 


+ Section 22.6, “Messenger Clustering Quick Checklist,” on page 229 


Planning Your Messenger System in a Linux Cluster 


Because the Messenger agents are not associated with GroupWise domains or post offices, the 
Messenger agents are easier to implement in a cluster than are the GroupWise agents. Section 22.5, 
“Messenger Clustering Worksheet,” on page 228 lists the information you need as you set up the 
Messenger agents in a clustering environment. You should print the worksheet and fill it out as you 
complete the tasks listed below: 

¢ Section 22.1.1, “Understanding Your Cluster,” on page 217 

+ Section 22.1.2, “Selecting the Messenger Partition and Secondary IP Address,” on page 218 


è Section 22.1.3, “Determining an Appropriate Failover List for the Messenger Agents,” on 
page 218 


+ Section 22.1.4, “Determining Cluster Resource Information for the Messenger Agents,” on 
page 218 


è Section 22.1.5, “Planning the Messenger Agent Installation,” on page 219 


Understanding Your Cluster 


As described in Section 13.1, “Installing Novell Cluster Services on Linux,” on page 122, you set up 
your cluster with a certain number of shared partitions and cluster resources. 


Implementing Messenger in a Linux Cluster 217 


22.1.2 


22.1.3 


22.1.4 


MESSENGER CLUSTERING WORKSHEET 


Under Items 1-5, record information about your cluster. This information corresponds to items 1-5 on 
the Section 13.7.1, “System Clustering Worksheet,” on page 128. 


Selecting the Messenger Partition and Secondary IP Address 


If you are not planning to enable archiving, or if you are not anticipating a large Messenger archive, 
you can use one Messenger partition for both the Messaging Agent and the Archive Agent. If you 
anticipate archiving a large number of messages so that the Messenger archive grows very large, you 
might want to have a separate Messenger partition for the Archive Agent and its archive database. 
The steps in this section focus on setting up the Messenger agents on a single Messenger partition. 


MESSENGER CLUSTERING WORKSHEET 


Under Item 6: Shared Partition for Messenger, record the name and secondary IP address of the 
Messenger partition in your cluster. 


If you want a separate Messenger partition for archiving, under Item 7: Shared Partition for Archiving, 
record the name and secondary IP address of the archiving partition in your cluster. 


Determining an Appropriate Failover List for the Messenger Agents 


By default, a Messenger partition is configured to have all nodes in the cluster in its failover list, 
organized in ascending alphanumeric order. Only one node at a time can have the Messenger 
partition mounted and active and the Messenger agents running. If a Messenger partition’s preferred 
node fails, the partition fails over to the next node in the failover list. The Messenger agents might 
need to run on any node that the Messenger partition fails over to. 


MESSENGER CLUSTERING WORKSHEET 


Under Item 8: Failover List for Messenger Agents, list the nodes that you want to have in the 
Messenger agents’ failover list. 


Determining Cluster Resource Information for the Messenger Agents 


A cluster resource is a shared partition, secondary IP address, application, service, Web server, etc., 
that can function successfully anywhere in the cluster. Cluster resources include the GroupWise 
agents and the Messenger agents. When you are installing the Messenger agents in a cluster, the 
Messenger Installation program needs to know the mount point for the Messenger partition where it 
can store agent startup files, log files, SSL certificate files, and the uid.conf file that enables the 
Messenger agents to run as a non-root user. By storing these files on a shared partition, the 
Messenger agents can access the files regardless of which node in the cluster the agents are currently 
running on. 


MESSENGER AGENT CLUSTERING WORKSHEET 


Under Item 9: Mount Point for Shared Storage, list the mount point directory for the Messenger partition 
where the Messenger startup and other files will be located. 
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22.1.5 


22.2 


22.2.1 


Planning the Messenger Agent Installation 


Aside from the cluster-specific issues discussed in the preceding sections, the considerations 
involved in planning to install the Messenger agents are the same in a clustering environment as for 
any other environment. Review “Planning Your Novell Messenger System”, then print and fill out 
the “Novell Messenger Worksheet” in “Installing a Novell Messenger System” in the Novell 
Messenger 2.1 Installation Guide. Messenger must be installed on each node in the failover list 
(Messenger Clustering Worksheet item 8) 


Continue with Setting Up Your Messenger System in a Linux Cluster. 


Setting Up Your Messenger System in a Linux Cluster 


You should have already reviewed Section 22.1, “Planning Your Messenger System in a Linux 
Cluster,” on page 217 and filled out the Section 22.5, “Messenger Clustering Worksheet,” on page 228 
and the “Novell Messenger Worksheet” in the Novell Messenger 2.1 Installation Guide. 


+ Section 22.2.1, “Creating Your Messenger System and Installing the Messenger Agents,” on 
page 219 


¢ Section 22.2.2, “Changing Messenger Paths to Locations on the Messenger Partition,” on 
page 221 


+ Section 22.2.3, “Configuring the Messenger Cluster Resource to Load and Unload the Messenger 
Agents,” on page 223 


Creating Your Messenger System and Installing the Messenger Agents 


The Messenger Installation program walks you through setting up your Messenger system and 
installing the Messenger agents. The first time you run the Messenger Installation program, you 
create your Messenger system, which includes creating various Messenger objects in eDirectory and 
installing the Messenger software on the node where you run the Messenger Installation program. 
After that, you run the Messenger Installation program on each node in the Messenger failover list to 
install the Messenger software on each node, but you do not create any more objects in eDirectory. 

+ “Running the Messenger Installation Program on the Preferred Node” on page 219 

+ “Running the Messenger Installation Program on Subsequent Nodes” on page 220 

¢ “Setting Up Non-root Access on NSS Volumes on Each Node” on page 220 


+ “Testing Your Messenger Agent Installation on Each Node” on page 220 


Running the Messenger Installation Program on the Preferred Node 


1 Mount the Messenger partition (Messenger Clustering Worksheet item 6) on the mount point for 
shared storage (Messenger Clustering Worksheet item 9). 


2 Run the Messenger Installation program, following the steps provided in “Starting the 
Messenger Installation Program on Linux” in “Installing a Novell Messenger System” in the 
Novell Messenger 2.1 Installation Guide. 


3 When asked if you are installing to a cluster, enter y for Yes. 
4 From the options list, enter 1 for Create a new system. 


5 Specify the mount point for the shared storage. 
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6 Set up your Messenger system, following the steps provided in “Configuring Your Messenger 
System on Linux” in “Installing a Novell Messenger System” in the Novell Messenger 2.1 
Installation Guide. 


7 Continue with Running the Messenger Installation Program on Subsequent Nodes. 


Running the Messenger Installation Program on Subsequent Nodes 


1 On the next node in the Messenger failover list (Messenger Cluster Worksheet item 8), mount 
the Messenger partition on the mount point for shared storage. 


Run the Messenger Installation program. 
When asked if you are installing to a cluster, enter y for Yes. 


From the options list, enter 2 for Install a new server to an existing system. 


ao fF U N 


Specify the mount point for the shared storage. 


The Messenger Installation program then accesses the Messenger files that were created on the 
shared storage when the Messenger agents were installed on the preferred node. From these 
files, the Messenger Installation program lists the probable configuration for the Messenger 
agents you are installing on the current node. 


6 Enter 1 for Proceed with these settings. 
or 


Enter 2 for Change the settings, then modify the configuration for the Messenger agents as 
needed. 


7 When asked if you want to start the agents, enter n for No. 
8 Repeat Step 1 through Step 7 for each node on the Messenger failover list. 
9 Continue with Setting Up Non-root Access on NSS Volumes on Each Node. 


Setting Up Non-root Access on NSS Volumes on Each Node 


If your cluster uses NSS volumes, as described in the OES 11 Novell Cluster Services 2 for Linux 
Administration Guide (http://www.novell.com/documentation/oes11/clus_admin_lx/data/ 
h4hgu4hs.html) , you must set up non-root access to those NSS volumes, as described in “Setting Up 
Non-root Access on an NSS Volume on Novell Open Enterprise Server Linux” in “Installing a Novell 
Messenger System” in the Novell Messenger 2.1 Installation Guide. Then continue with Testing Your 
Messenger Agent Installation on Each Node. 


Testing Your Messenger Agent Installation on Each Node 


1 Test the Messenger agents by starting them as daemons, as described in “Starting the Linux 
Messenger Agents” in “Installing a Novell Messenger System” in the Novell Messenger 2.1 
Installation Guide. 


/etc/init.d/novell-nmma start 
/etc/init.d/novell-nmaa start 
/etc/init.d/novell-nmma status 
/etc/init.d/novell-nmaa status 


2 Stop the Messenger agents. 
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22.2.2 


/etc/init.d/novell-nmma stop 
/etc/init.d/novell-nmaa stop 
/etc/init.d/novell-nmma status 
/etc/init.d/novell-nmaa status 


3 Return to “Running the Messenger Installation Program on the Preferred Node” on page 219 for 
each node in the Messenger failover list (Messenger Clustering Worksheet item 8). 


When you have installed the Messenger agents on all of the nodes in the Messenger failover list, 
continue with Changing Messenger Paths to Locations on the Messenger Partition. 


Changing Messenger Paths to Locations on the Messenger Partition 


During installation, various Messenger paths are set to locations on the node where the software is 
installed. After installation, you need to set these paths to locations on the Messenger partition, so 
that the files stored at these locations are available to the Messenger agents regardless of which node 
in the cluster the agents are running on: 

¢ “Setting the Store Path” on page 221 

¢ “Setting the Messaging Agent Queue Path” on page 221 

¢ “Setting the Archive Agent Queue Path” on page 222 

¢ “Setting the Messaging Agent Log Path” on page 222 

¢ “Setting the Archive Agent Log Path” on page 222 


After settings these directories, continue with Section 22.2.3, “Configuring the Messenger Cluster 
Resource to Load and Unload the Messenger Agents,” on page 223. 


Setting the Store Path 


The store path is the location where you want the archive created. During installation, the default 
store path is created in /var/opt /novell/messenger/aa/store on each node, but you need the 
archive to be stored on the Messenger partition. 


1 Choose a directory where you want to store the archive and create that directory on the 
Messenger partition. 


2 In ConsoleOne, browse to and select the Novell Messenger Service object (MessengerService), 
then click Messenger Server > Archive Agent. 


3 Right-click the File Module object, then click Properties. 
4 Inthe Store Path field, specify your archive store path, then click OK. 


Setting the Messaging Agent Queue Path 


When archiving is enabled, the Messaging Agent passes conversations to the Archive Agent when 
the conversations are completed. If the Messaging Agent cannot communicate with the Archive 
Agent when it has a conversation to archive, it saves the conversation in its holding directory (queue) 
until it can communicate with the Archive Agent again. During installation, the default Messaging 
Agent queue path is created in /var/opt /novell/messenger/ma/queue, but you need the queue 
directory to be located on the Messenger partition. 


1 Choose a directory for the Messaging Agent queue and create that directory on the Messenger 
partition. 


2 In ConsoleOne, browse to and select the Novell Messenger Service object (MessengerService), 
then click Messenger Server. 
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3 Right-click the Messaging Agent object, then click Properties. 
4 Click Agent > Messaging. 
5 Inthe Messaging Queue Path field, specify the Messaging Agent queue path, then click OK. 


Setting the Archive Agent Queue Path 


When the Archive Agent receives a conversation to archive, if it is already busy processing other 
conversations, it temporarily stores the conversation in its holding directory (queue). During 
installation, the default Archive Agent queue path is created in /var/opt/novell/messenger/aa/ 
queue, but you need the queue directory to be located on the Messenger partition. 


1 Choose a directory for the Archive Agent queue and create that directory on the Messenger 
partition. 


2 In ConsoleOne, browse to and select the Novell Messenger Service object (MessengerService), 
then click Messenger Server. 


3 Right-click the Archive Agent object, then click Properties. 
4 Click Agent > Messaging. 
5 Inthe Messaging Queue Path field, specify the Archive Agent queue path, then click OK. 


Setting the Messaging Agent Log Path 


During installation, the default Messaging Agent log path is created in /var/opt /novell/log/ 
messenger/ma, but you need the log file directory to be located on the Messenger partition. 


1 Choose a directory for the Messaging Agent log files and create that directory on the Messenger 
partition. 


2 In ConsoleOne, browse to and select the Novell Messenger Service object (MessengerService), 
then click Messenger Server. 


3 Right-click the Messaging Agent object, then click Properties. 
4 Click Agent > Log Settings. 
5 Inthe Log Files Path field, specify the Messaging Agent log path, then click OK. 


Setting the Archive Agent Log Path 


During installation, the default Archive Agent log path is created in /var/opt/novell/log/ 
messenger/aa, but you need the log file directory to be located on the Messenger partition. 


1 Choose a directory for the Archive Agent queue and create that directory on the Messenger 
partition. 


2 In ConsoleOne, browse to and select the Novell Messenger Service object (MessengerService), 
then click Messenger Server. 


3 Right-click the Archive Agent object, then click Properties. 
4 Click Agent > Log Settings. 
5 In the Log Files Path field, specify the Archive Agent log path, then click OK. 
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22.2.3 


Configuring the Messenger Cluster Resource to Load and Unload the 


Messenger Agents 


The properties of the Messenger Cluster Resource object define how the Messenger partition 


functions within the cluster, how the Messenger agents are loaded and unloaded, and how failover 


and failback situations are handled. 


e “Modifying the Cluster Load Script for the Messenger Agents” on page 223 
e “Modifying the Cluster Resource Unload Script for the Messenger Agents” on page 224 
¢ “Setting the Failover List and Policies for the Messenger Agents” on page 226 


Modifying the Cluster Load Script for the Messenger Agents 
To set up the load script in iManager: 


1 Expand Clusters, then click Cluster Options. 


2 Inthe Cluster field, browse to the Cluster object where the Messenger cluster resource is located. 


3 Click the Cluster object to display the cluster resources that belong to the cluster. 


4 Select the Messenger cluster resource that you created when you set up the Messenger partition, 


then click Properties. 


The default load script from a generic IP service template appears as follows: 


#!/bin/bash 
. /opt/novell/ncs/lib/ncsfuncs 


# mount the file system 
exit _on_error mount -t reiserfs /dev/evms/vol /mnt/generic 


# add the IP address 
exit_on_error add_secondary_ipaddress a.b.c.d 


# start the service 
exit_on_error /etc/init.d/myservice start 


# return status 
exit 0 





5 If this is an NSS volume or a shared pool, make the following changes to set up the Messenger 


load script: 


5a As needed, in the mount command, change reiserfs to whatever file system type is in use 


on nodes in the cluster. 


5b In the mount command, change vol to the actual device name in use on nodes in the cluster. 


5c In the mount command, change /mnt/generic to the mount point directory in use on nodes 


in the cluster. 


5d In the add_secondary_ipaddress command, change a.b.c.d to the secondary IP address 


of the Messenger partition. 


5e In the start service command, change myservice start to the command to start the 
Messenger agents. 


/etc/init.d/novell-nmma start 
/etc/init.d/novell-nmaa start 


6 If this is a traditional Linux volume, use the following load script: 
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#! 


/bin/bash 


/opt/novell/ncs/lib/ncsfunc 


# define the IP address 
RESOURCE IP=123.123.1. 


# define the file system type 
MOUNT_FS=reiserf 


# define the device 


exi 


t_on_error evms -f /var/opt/novell/ncs/ContainerActivate -rl 
Share ‘uname -n` 


MOUNT_DEV=/dev/evms/Share/dat 


# define the mount point 
MOUNT_POINT=/mnt/mount_point 


# mount the file system 


exi 


t_on error mount -t SMOUNT_FS SMOUNT_DEV SMOUNT_POINT 


# add the IP address 


exi 


t_on_error add_secondary_ipaddress SRESOURCE_IP 


/etc/init.d/novell-nmma start 
/etc/init.d/novell-nmaa start 


exit 





0 


Make the following changes to set up the load script for the Messenger agents: 


6a 


6b 


6c 


6d 


6e 


6f 


On the RESOURCE_IP line, change 123.123.1.1 to the secondary IP address of the 
GroupWise partition (Messenger Clustering Worksheet item 6 and Messenger Clustering 
Worksheet item 7) 


As needed on the MOUNT_FS line, change reiserfs to whatever file system type is in use on 
nodes in the cluster. 


On the MOUNT_DEV line, change /dev/evms/Share/dat to the actual device name in use on 
nodes in the cluster. 


On the MOUNT_POINT line, change /mnt/mount_point to the mount point directory in use 
on nodes in the cluster. 


Use the following command to start the Messaging Agent: 


/etc/init.d/novell-nmma start 


Use the following command to start the Archive Agent: 


/etc/init.d/novell-nmaa start 


7 Click Apply to save the load script. 


Modifying the Cluster Resource Unload Script for the Messenger Agents 


The cluster resource unload script executes whenever the Messenger cluster resource goes offline. 


1 On the Cluster Resource Properties page of the Monitor Agent cluster resource, click Scripts > 
Unload Script. 


The default unload script appears as follows: 
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#!/bin/bash 
/opt/novell/ncs/lib/ncsfuncs 


# request service stop 
ignore error /etc/init.d/myservice stop 


# stop service otherwise 
sleep 8 
ignore error fuser -k /mnt/generic 


# del the IP address 
ignore_error del_secondary_ipaddress a.b.c.d 


# umount the file system 
exit_on_error umount /mnt/generic 


# return status 
exit 0 


2 If this is an NSS volume or a shared pool, make the following changes to the Messenger unload 
script: 
2a In the stop service command, change myservice stop to the command to stop the 
Messenger agents. 


/etc/init.d/novell-nmma stop 
/etc/init.d/novell-nmaa stop 


2b Adjust the sleep command as needed so that the Messenger agents can shut down 
normally on your system without being inadvertently killed by the fuser -k command 
that follows. 


2c In the kill service command, used if the Messenger agents do not stop normally, change -k 
to -mk. 


The -m parameter obtains the PID numbers of the processes to kill. 


2d _ In the kill service command, change /mnt /generic to the mount point directory used in the 
load script. 


2e In the del_secondary_ipaddress command, change a.b.c.d to the secondary IP address 
used in the load script. 


2f In the umount command, change /mnt/generic to the mount point directory used in the 
load script. 


3 If this is a traditional Linux volume, use the following unload script: 
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#!/bin/bash 
/opt/novell/nces/lib/nesfuncs 


/etc/init.d/novell-nmma stop 
/etc/init.d/novell-nmaa stop 


# define the IP address 
RESOURCE IP=172.16.5.18 


# define the mount point 
MOUNT_POINT=/mnt/mount_point 


sleep 8 
ignore_error fuser -k SMOUNT_POINT 


# del the IP address 
ignore_error del_secondary_ipaddress SRESOURCE_IP 


# umount the file system 
exit_on_error umount SMOUNT_POINT 


# return status 
exit 0 


Make the following changes to set up the unload script for the Messenger agents. 


3a Use the following command to stop the Messaging Agent: 


/etc/init.d/novell-nmma stop 


3b Use the following command to stop the Archive Agent: 
/etc/init.d/novell-nmaa stop 


3c On the RESOURCE_IP line, change 172.16.5.18 to the secondary IP address used in the 
load script. 


3d On the MOUNT_POINT line, change /mnt /mount_point to the mount point directory used in 
the load script. 


3e Adjust the sleep command as needed so that the Messenger agents can shut down 
normally on your system without being inadvertently killed by the fuser -k command 
that follows. 


3f Inthe fuser -k command (used if the agents do not stop normally), change -k to -mk. 
The -m parameter obtains the PID numbers of the processes to kill. 


4 Click Apply to save the unload script. 


Setting the Failover List and Policies for the Messenger Agents 


1 On the Cluster Resource Properties page of the Messenger cluster resource, click General. 
The default policy settings are often appropriate. By default, a cluster resource: 
¢ Fails over automatically if the node it is running on fails 
¢ Starts automatically on the next node in its failover list 


¢ Continues running at its failover location, even after its most preferred node is again 
available 


If you are considering changing these defaults, see the OES 11 Novell Cluster Services 2 for 
Linux Administration Guide (http://www.novell.com/documentation/oes11/clus_admin_lx/ 
data/h4hgu4hs.html). 
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2 Under Preferred Nodes, arrange the nodes in the cluster into the desired failover list for the 


Messenger agents (under Messenger Clustering Worksheet item 3). 


3 Click OK. 


22.3 Testing Your Clustered Messenger System 


After you have configured the Messenger cluster resource, you can test the load and unload scripts 
by bringing the Messenger cluster resource online and taking it offline again. 


1 IniManager, expand Clusters, then click Cluster Manager. 





ere Access a a E [s] [2] A N 


@ Roles and Tasks 


All Categories 7] 


Archive Versioning =! Cluster Manager 
EI Clusters View or change cluster server and resource status, 





Clusters » Cluster Manager 


Cluster Manager 


Cluster Event Log Cluster: |gw-clusterlx servers.novell Eral 
Cluster Options Run Report 
eDirectory Administration 


eDirectory Maintenance 
File Access (NetStorage) B K 


File Protocols 


Epoch: 1 


gw-5 gw-7 
Groups 


Œ Help Desk Cluster State View 


iFolder Management Online | Offline | Migrate | Respond to Alert 














‘Print fr Type Name ~ State ~ Location Lives Up Since 
Prnt X 
LDAP a Master_IP_Address_Resource @ ane gw-5 1 an ea gogos 
Linux User Management 
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E k Running a 3:04:19 PM 
Novell Certificate Access ce noa Offline : 
Novell Certificate Server Update | _Update Interval...| 
Partition and Replica Management SSS ESS 
cite =| EE zi 


The new Messenger cluster resource shows Offline in the State column. 


Click the new Messenger cluster resource, then click Online. 





Clusters > Cluster Manager > Online 





fall Categories >| 


Archive Versioning Resource: Mesa 
E Clusters Select the cluster node where you want the resource to load. 
Cluster Manager 
State: =) Offline 


Cluster Event Log 
Cluster Options 


eDirectory Administration Online Node Target: 
eDirectory Maintenance 


File Access (NetStorage) 


File Protocols 


we 2 


3 Select the cluster node where you want to online the Messenger cluster resource, then click OK. 


After a moment, the Messenger cluster resource displays Running in the State column. 
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4 At the server where the Messenger agents are starting, use the following commands to see that 
the Messenger agents have started: 


/etc/init.d/novell-nmma status 
/etc/init.d/novell-nmaa status 


5 Select the new Messenger cluster resource, then click Offline. 
The State column for the Messenger cluster resource returns to Offline. 


6 Use the same command that you used in Step 4 to verify that the Messenger agents have 
stopped. 


7 Repeat Step 2 whenever you are ready to bring the new Messenger cluster resource online 
permanently. 


8 Continue with Managing Your Clustered Messenger System. 


22.4 Managing Your Clustered Messenger System 


If the node where your Messenger system is running goes down, it fails over to the next node it its fail 
over list. Messenger clients reconnect automatically as soon as the Messaging Agent restarts on the 

next node. Users who are actively carrying on conversations notice the interruption, but do not need 
to do anything to reestablish their conversation when the Messaging Agent is up and running again. 


In comparison to failover, migration typically takes longer because the Messaging Agent 
methodically terminates its thread as part of its normal shutdown procedure. 


22.5 Messenger Clustering Worksheet 


Item Explanation 


1) eDirectory Tree for Cluster: Record the eDirectory tree where you created the Novell 
Cluster object when you installed Novell Cluster Services. 


For more information, see Section 13.1, “Installing Novell 
Cluster Services on Linux,” on page 122. 


2) Cluster Name: Record the name of the name of the Cluster object where your 
Messenger system will be located. Also record the master IP 
Master IP Address: address of the cluster. 


For more information, see Section 2.2, “Installing Novell 
Cluster Services,” on page 20. 


3) Cluster Context: Record the full context where you created the Cluster object. 


For more information, see Section 13.1, “Installing Novell 
Cluster Services on Linux,” on page 122. 


4) Nodes in Cluster List the nodes that are part of the cluster that will include 
Messenger. Also list technical information, including file system 
+ File system type type (reiserfs, ext3, etc.), device name (sda2, hda1, etc.), 
* Device name and mount point directory (/mnt, /mail, etc.) in use on the 
i nodes the cluster. You need this information as you create load 
* Mount point and unload scripts for the Messenger agents. 


For more information, see Section 13.1, “Installing Novell 
Cluster Services on Linux,” on page 122. 
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22.6 


Item 


5) Shared Partitions in Cluster: 


6) Messenger Partition for Messaging 
Agent: 


Secondary IP address: 
Use Same Partition for Archive Agent? 


+ Yes 


+ No 


7) Messenger Partition for Archive 
Agent? 


Secondary IP Address: 


8) Failover List for Messenger Agents: 


9) Mount Point for Shared Storage: 


Explanation 


List the shared partitions that are available for use in your 
Messenger system. 


For more information, see Section 13.1, “Installing Novell 
Cluster Services on Linux,” on page 122. 


The Messaging Agent software is installed on each node in its 
failover list but it does use a shared partition to store its log 
files, temporary files, and queue directories. Specify the name 
of the shared partition in the your cluster that the Messaging 
Agent can use for these purposes. also specify the secondary 
IP address of that shared partition. 


For more information, see “Selecting the Messenger Volume” 
on page 109. 


In addition to the data storage needs of the Messaging Agent, 
the Archive Agent can be configured to store all instant 
message conversations. It is possible that this might consume 
a large quantity of disk space. If so, you could choose to use a 
separate shared partition for the Archive Agent. 


For more information, see “Selecting the Messenger Volume” 
on page 109. 


List other nodes in the cluster where the Messenger agents 
can fail over. You might want to have the same nodes on the 
both agents’ lists or have separate lists for each agent. It 
depends on the loads that each agent will be carrying. 


For more information, see “Determining an Appropriate 
Failover Path for the Messenger Volume” on page 109. 


Specify the mount point directory where the shared resource is 
mounted to the cluster node where the Messenger Agents run. 


For more information, see Section 22.1.4, “Determining Cluster 
Resource Information for the Messenger Agents,” on 
page 218. 


Messenger Clustering Quick Checklist 


O Plan your clustered Messenger system. 


See Section 22.1, “Planning Your Messenger System in a Linux Cluster,” on page 217. 


O Create your Messenger system and install the Messenger agents. 


See Section 22.2.1, “Creating Your Messenger System and Installing the Messenger Agents,” on 


page 219. 


O If you use NSS volumes in your cluster, configure the Messenger agents so that they run as a 


non-root user. 


See “Setting Up Non-root Access on NSS Volumes on Each Node” on page 220. 


O InConsoleOne, change the locations of various Messenger files from their default locations on 


local nodes to the Messenger partition that is always available not matter what node the 
Messenger agents are running on. 
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See Section 22.2.2, “Changing Messenger Paths to Locations on the Messenger Partition,” on 
page 221. 


O Modify the Messenger agents cluster resource load script. 
See “Modifying the Cluster Load Script for the Messenger Agents” on page 223. 
O Modify the Messenger agents cluster resource unload script. 
See “Modifying the Cluster Resource Unload Script for the Messenger Agents” on page 224. 
C Set up the Messenger agents failover list and policies. 
See “Setting the Failover List and Policies for the Messenger Agents” on page 226. 
O Test your clustered Messenger system. 


See Section 22.3, “Testing Your Clustered Messenger System,” on page 227. 
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Novell Vibe 


Before installing Novell Vibe, you should thoroughly review the documentation provided at the 
Novell Vibe 3.2 documentation Web site (http://www.novell.com/documentation/vibe32). These 
guides provide detailed product installation and configuration instructions, but they do not include 
specific instructions for integrating Novell Vibe with eDirectory or GroupWise. This section of the 
GroupWise 8 Interoperability Guide supplies these product-specific instructions. 


¢ Chapter 23, “Configuring GroupWise for Use with Novell Vibe,” on page 233 
¢ Chapter 24, “Accessing Your Vibe Site from the GroupWise Client,” on page 237 
¢ Chapter 25, “Streamlining Authentication to Vibe,” on page 239 





NOTE: Novell Vibe 3.2 is the next major product release after Novell Teaming 2.1. 
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Configuring GroupWise for Use with 
Novell Vibe 


When you install Novell Vibe with eDirectory and GroupWise, some configuration steps are required 
to integrate the applications. 


+ Section 23.1, “Understanding How Novell Vibe Interacts with eDirectory and GroupWise,” on 
page 233 

è Section 23.2, “Using eDirectory as the Vibe LDAP Directory,” on page 233 

* Section 23.3, “Using GroupWise as the Vibe E-Mail System,” on page 234 


è Section 23.4, “Enabling GroupWise/Vibe Integration for GroupWise Windows Client Users,” on 
page 234 


23.1 Understanding How Novell Vibe Interacts with eDirectory 
and GroupWise 


When you install Novell Vibe in an environment where eDirectory and GroupWise are already set 
up, the products interact in the following ways: 


¢ Vibe can use eDirectory for LDAP authentication of Vibe users. This means that you do not need 
to create Vibe users manually. Vibe can create its user accounts based on the users that already 
exist in eDirectory. 


¢ Vibe can use GroupWise as its integrated e-mail system. This means that e-mail messages sent 
from the Vibe site are delivered to GroupWise mailboxes. It also means that GroupWise users 
can post items to Vibe folders by sending e-mail messages to Vibe folders. 


¢ Vibe information can be displayed in the GroupWise Windows client. Starting in GroupWise 
8.0.2, you can drag and drop GroupWise items into Vibe folders in the GroupWise Folder List to 
post items to the corresponding folders in your Vibe site. You can also use the GroupWise Find 
feature to search your Vibe site. 


23.2 Using eDirectory as the Vibe LDAP Directory 


For instructions, see the following sections of the Novell Vibe OnPrem 3 Installation Guide: 


+ “Gathering Directory Services Information” in “Planning a Basic Vibe Installation” 


+e “Adding Users to Your Vibe Site” in “Basic Installation” 
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23.3 


23.4 


Using GroupWise as the Vibe E-Mail System 


For setup instructions, see the following sections of the Novell Vibe OnPrem 3 Installation Guide: 


+ “Gathering Outbound E-Mail Information” in “Planning a Basic Vibe Installation” 


¢ “Enabling Inbound E-Mail” in “Planning a Basic Vibe Installation” 

See also the following section of the Novell Vibe OnPrem 3 Administration Guide: 
¢ “Configuring E-Mail Integration” 

For basic e-mail usage instructions, see the following sections of the Novell Vibe OnPrem 3 User Guide: 
+ “Sending E-Mail to Team Members and Announcing the Workspace after Its Creation” in 


“Managing and Using Workspaces” 


¢ “Subscribing to E-Mail Notifications from a Folder”, “Setting Up a Folder to Receive Entries Via 
E-Mail” and “Adding Entries to a Folder Via E-Mail” in “Managing and Using Folders” 


¢ “Sending E-Mail from within Vibe” in “Connecting With Your Co-Workers” 
See also the following sections of the Novell Vibe OnPrem 3 Advanced User Guide: 
+ “Enabling Folders to Receive Entries through E-Mail” and “Configuring Folders to Send E-Mail 
Notifications to Other Users” in “Managing Folders” 
¢ “Sending E-Mail Notifications” in “Creating and Managing Workflows” 


¢ “E-Mailing Files and Attachments to the Vibe Site When You Are Over Your Quota” in 
“Managing Your Data Quota” 


¢ “Sending E-Mail” in “Using Vibe on Your Mobile Phone” 


Enabling GroupWise/Vibe Integration for GroupWise 
Windows Client Users 


Before you can integrate GroupWise and Vibe, your Vibe site must be set up, as described in the 
Novell Vibe OnPrem 3 Installation Guide. 


1 In ConsoleOne, browse to and select a Domain object, Post Office object, or User object where 
you want to make Vibe available to GroupWise Windows client users. 
2 Click Tools > GroupWise Utilities > Client Options. 


3 Click Environment > Teaming. 
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Environment Options: Provo1 


General | Client Access | Views | File Location | Cleanup | Appearance | Retention 
Junk Mail Calendar ul ing i Tutorial Address Book Conferencing 


[C Enable Teaming 
] S 





Restore Default Settings 








NOTE: Novell Vibe 3.2 is the next major product release after Novell Teaming 2.1. 





4 Select Enable Teaming. 
5 Provide the Vibe URL: 
5a Specify the fully qualified hostname of the Vibe server: 
vibe_server.domain 
For example: 
vibe. yourcompanyname.com 


ConsoleOne provides the rest of the default Vibe URL, which uses a secure HTTPS 
connection, assumes the default port number, and includes the default location for the Vibe 
Web service that communicates with other applications: 


https://vibe_server.domain/ssf/ws/TeamingServiceV1 


5b (Conditional) If you want to use HTTP instead of HTTPS, include it in the Teaming URL 
field, for example: 


http: //vibe.yourcompanyname.com 


5c (Conditional) If Vibe is not configured with the default HTTPS port, include the port 
number after the hostname, for example: 


vibe. yourcompanyname.com:444 


5d (Conditional) If Vibe is not installed in the default location, include the path to 
TeamingServiceV1, for example: 


vibe. yourcompanyname.com/Web/Teaming/TeamingServiceV1 


6 Click OK. 
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IMPORTANT: In order for GroupWise users to take advantage of GroupWise/Vibe integration, they 
must provide their GroupWise email address in their Vibe profile. 
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Accessing Your Vibe Site from the 
GroupWise Client 


Before you can access the Vibe site from the GroupWise Windows client, you must add your 
GroupWise email address to your Vibe profile, as described in “Modifying Your Profile” in “Getting 
Started” in the Novell Vibe 3.2 User Guide. 


By providing the Vibe site URL in ConsoleOne, you provide GroupWise Windows client users with 
the functionality described in “Novell Vibe OnPrem” in the GroupWise 8 Windows Client User Guide. 





NOTE: Vibe is not integrated with the GroupWise Linux/Mac client. 
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25.1 


25.1.1 


25.1.2 


Streamlining Authentication to Vibe 


You can implement single sign-on for use with Novell Vibe. 


+ Section 25.1, “Using iChain for Authenticating to Vibe,” on page 239 
+ Section 25.2, “Using Novell Access Manager for Authenticating to Vibe,” on page 241 


Using iChain for Authenticating to Vibe 


You can use Novell iChain to eliminate a dual user login into your network and into Vibe. The 
instructions in this section assume that you have an understanding of iChain, as described on the 
Novell iChain 2.3 Documentation Web site (http://www.novell.com/documentation/ichain23) and 
that you have iChain set up and running on your system. 


There are many ways to configure iChain. This section illustrates one possible way to configure 
iChain to support Vibe. Before following the steps in this section, you must have Vibe, as well as 
iChain, installed, configured, and running. 

+ Section 25.1.1, “Meeting iChain Requirements,” on page 239 

+ Section 25.1.2, “Setting Up an iChain Web Server Accelerator for Vibe,” on page 239 


+ Section 25.1.3, “Adding the New Web Server Accelerator to the iChain Server Object in 
ConsoleOne,” on page 240 


è Section 25.1.4, “Using iChain for Authentication,” on page 241 


Meeting iChain Requirements 


In order to get the best performance and reliability from iChain with Vibe, you must install iChain 2.3 
Support Pack 5 Release 4 version 2.3.410. This software is available on the iChain Patches tab on the 
Novell Downloads Web site (http://download.novell.com). Follow the installation instructions that 
are provided with the patch. 


Setting Up an iChain Web Server Accelerator for Vibe 


1 Access the iChain Proxy Administration Tool at the following URL: 
http://proxy_server_address:port/appliance/config.html 

2 Click Configure, then click Insert to create a new Web server accelerator for Vibe. 
The new accelerator is enabled by default. 

3 Inthe Name field, provide a unique and descriptive name for the new accelerator. 
For example, you might want to call it Vibe. 

4 Select Allow Pages to Be Cached at the Browser. 
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5 Select Enable Multi-Homing. 


10 


5a In the Multi-Homing Options dialog box, select Domain-Based Multi-Homing to configure 
the Vibe URL as a DNS name prepended to your Internet domain name, for example: 


http://vibe.yourcompanyname.com 


The A record for the DNS name must already exist. The Proxy Administration Tool does 
not create it for you. 


5b In the DNS Name field, specify the DNS A record. 
5c Click OK to save your multi-homing settings. 


If you have created a custom login page for your Vibe Web site, specify it in the Custom Login 
Page Location field. 


The default location for custom login pages is sys: \etc\proxy\data. The custom login page 
must be an HTML file with a . htm extension. If it is located in a directory other than the default, 
specify the full pathname for the file. 


Select Enable Secure Exchange. 


7a In the Port field on the right, specify the port number that the iChain proxy server should 
use to communicate with the Web server where Vibe is installed. 


7b If desired, select Enable Secure Access between the iChain Proxy and the Origin Web Server. 
7c Click OK to save your secure exchange options. 
Under the Web Server Addresses box, click Insert. 
8a Specify the IP address or DNS hostname of the Web server where you have installed Vibe. 
8b Click OK to add the Web server to the list in the Web Server Accelerator dialog box. 
Click OK to save the new Web server accelerator. 


Continue with Adding the New Web Server Accelerator to the iChain Server Object in 
ConsoleOne. 


25.1.3 Adding the New Web Server Accelerator to the iChain Server Object in 
ConsoleOne 


1 Start ConsoleOne in a location where the iChain snap-ins are installed. 


2 


Browse to and right-click the iChain Server object, then click Properties. 


3 Click Protected Resource to display a list of protected resources. 


4 Click the Plus icon to add a new protected resource. 


4a In the Resource Name field, provide a unique and descriptive name for the new protected 
resource, which is the Web server accelerator. 


4b In the URL Prefix field, specify the part of the URL that precedes the application-specific 
part of the URL; for example: 


vibe. yourcompanyname.com/* 


Ac Select the type of access you want to provide for users to view the URL: Secure, Restricted, or 
Public. 


4d Click OK to save the new protected resource. 


5 Select the new protected resource, then click the Parameters icon to display the OLAC Parameters 


dialog box. 
5a In the Name column, specify Authorization. 


5b In the Data Source column, specify ldap. 
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5c In the Value column, specify cn. 


These settings add an extended HTTP request header called X-Authorization that stores 
each user’s cn (common name). The cn is retrieved from the LDAP server by the iChain 
OLAC process so that users can log in automatically. 


5d Click OK to save the OLAC parameters. 
6 When prompted, click Yes to refresh the iChain proxy configuration with the new changes. 


7 Provide the password to the proxy server, then click OK to perform the refresh operation 
immediately. 


25.1.4 Using iChain for Authentication 


Now that you have created an iChain Web server accelerator for Vibe and have configured the iChain 
Server object for the new Web server accelerator, users should be able to authenticate to Vibe in a 
single step, using their eDirectory or LDAP passwords. 


25.2 Using Novell Access Manager for Authenticating to Vibe 


See “Configuring Single Sign-On with Novell Access Manager” in “Advanced Installation and 
Reconfiguration” in the Novell Vibe OnPrem 3 Installation Guide. 
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Novell Conferencing 


Before installing Novell Conferencing you should thoroughly review the documentation provided at 
the Novell Conferencing documentation Web site (http://www.novell.com/documentation/ 
novell_conferencing). These guides provide detailed product usage instructions, but they do not 
include specific instructions for integrating Novell Conferencing with GroupWise. This section of the 
GroupWise 8 Interoperability Guide supplies these product-specific instructions. 


¢ Chapter 26, “Using GroupWise with Conferencing,” on page 245 
¢ Chapter 27, “Accessing Conferencing Features in the GroupWise Client,” on page 247 
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26.1 


Using GroupWise with Conferencing 


When you set up Novell Conferencing with GroupWise, some configuration steps are required to 
integrate the applications. 


+ Section 26.1, “Enabling GroupWise/Conferencing Integration for GroupWise Windows Client 
Users,” on page 245 


+ Section 26.2, “Using Conferencing Features in the GroupWise Windows Client,” on page 246 


Enabling GroupWise/Conferencing Integration for 
GroupWise Windows Client Users 


Before you can integrate GroupWise and Conferencing, Conferencing must be set up. For more 
information, see the Novell Conferencing documentation Web site (http://www.novell.com/ 
documentation/novell_conferencing). 


1 In ConsoleOne, browse to and select a Domain object, Post Office object, or User object where 
you want to make Conferencing available to GroupWise Windows client users. 


2 Click Tools > GroupWise Utilities > Client Options. 


3 Click Environment > Conferencing. 


Environment Options: Provo1 


General | Client Access | Views | File Location | Cleanup | Appearance | Retention. 
Junk Mail | Calendar = Teaming | Tutorial Address Book |, Conferencing į 


C Enable Conferencing 
S 





Restore Default Settings 





4 Select Enable Conferencing. 
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5 Specify the URL of the Novell Conferencing server. 
6 Click OK. 


26.2 using Conferencing Features in the GroupWise Windows 
Client 


By providing the Conferencing site URL in ConsoleOne, you provide GroupWise Windows client 
users with the functionality described in “Conferencing” in the GroupWise 8 Windows Client User 


Guide. 
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2 Accessing Conferencing Features in the 
GroupWise Client 


By providing the Conferencing URL in ConsoleOne, you provide GroupWise Windows client users 
with the functionality described in “Conferencing” in the GroupWise 8 Windows Client User Guide. 





NOTE: Conferencing is not integrated with the GroupWise Linux/Mac client. 





Accessing Conferencing Features in the GroupWise Client 247 


248 GroupWise 8 Interoperability Guide 


VV Novell ZENworks 


+ Chapter 28, “Using ZENworks 10 Configuration Management to Distribute the GroupWise 
Windows Client,” on page 251 


¢ Chapter 29, “Using ZENworks 7 Desktop Management to Distribute the GroupWise Windows 
Client,” on page 257 


¢ Chapter 30, “Using ZENworks Linux Management to Distribute the GroupWise Linux/Mac 
Client,” on page 265 


¢ Chapter 31, “ZENworks Application Virtualization for GroupWise and Messenger,” on page 267 
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Using ZENworks 10 Configuration 
Management to Distribute the 
GroupWise Windows Client 


You can use the Configuration Management functionality in Novell ZENworks 10 to distribute the 
GroupWise Windows client to workstations. 

è Section 28.1, “Creating ZENworks Bundles,” on page 251 

+ Section 28.2, “Setting the Security Level for Each Bundle,” on page 254 

+ Section 28.3, “Configuring Each Bundle,” on page 255 





IMPORTANT: This information assumes that you are familiar with ZENworks 10.3 Configuration 
Management. For background information, or for help completing the ZENworks tasks outlined in 
the steps below, see the ZENworks Configuration Management documentation at the Novell 
ZENworks Documentation Web site (http://www.novell.com/documentation/zcm10). 





28.1 Creating ZENworks Bundles 


To install the GroupWise Windows client software, you must distribute the following .msi files. 


+ wse3.msi 
+ msxml.msi 


* groupwise.msi 
To create a ZENworks bundle for each .msi file: 


1 In ZENworks Control Center, click Bundles, then click New > Bundle. 
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Bundles > Create New Bundle 


Create New Bundle 
© Step 1: Select Bundle type 


Select the type of Bundle yo 





to create from the list of options. 


New Bundle Type: Description: 
Directive Bundle - Select this option to create a bundle which performs a set of tasks on a 
number of managed devices, regardless of platform. 






File Bundle 
Imaging Bundle 
‘Windows Bundle 








<< Back Next >> | Cancel 








2 Select Windows Bundle, then click Next. 


Bundles > Create New Windows Bundle 


Create New Windows Bundle 
© Step 2: Select Bundle category 


Select the category of Bundle you wish to create from the list of options. 


New Bundle Category: Description: 
(Empty Bundle) - Select this option to create a bundle with no initial tasks. 












MSI Application 
MSP Application 
Simple Application 
Thin Client Application 
Web Application 











| <« Back Next>> | | Cancel 





3 Select MSI Application, then click Next. 
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Bundles > Create New Windows Bundle 


Create New Windows Bundle 
© Step 3: Define Details 


Enter the details for the bundle, 


Bundle Name: * 








Folder: * 








|/Bundles E 
Icon: 

E 
Description: 











Fields marked with an asterisk are required. 








<< Back Next >> Cancel | 





4 Specify a name for the bundle, such as WSE3, MSXML, or GroupWise Windows Client, then click 
Next. 


Bundles > Create New Windows Bundle 


Create New Windows Bundle WSE3 
© Step 4: Select .msi File 


Select the .msi file and parameters for the application 


.msi File: * 
© Upload .msi file for normal install: 


E 


O Enter UNC path of .msi file for network install: 


5 Select the .msi file for the bundle that you are creating: 
5a In the Upload .msi file for normal install field, browse to and select the .msi file in your 
GroupWise software distribution directory: 


\grpwise\software\client\win32 


Select .msi File [x] 


„msi File: 


[ Browse 


Include all files in and below the directory of this file 














Status: 














5b (Conditional) If you are creating a bundle for the wse3 .msi or msxml.msi file, do not select 
Include all files in and below the directory of this file. 


or 


(Conditional) If you are creating a bundle for the groupwise.msi file, select Include all files 
in and below the directory of this file. 
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This includes all the contents of the win32 subdirectory, which is the GroupWise client 
software. 


5c Click OK. 


Bundles > Create New Windows Bundle 


Create New Windows Bundle WSE3 
© Step 4: Select .msi File 


Select the .msi file and parameters for the application. 


-msi File: * 
© upload .msi file for normal install: 
wse3_msi 





O Enter UNC path of .msi file for network install: 








Select the parameters for msiexec. 
Install Parameters: * 
/i wse3.msi /qn 





ai 


Uninstall Parameters: 
/x wse3.msi /qn 





ai 





Repair Parameters: 
/f wse3.msi /qn 











fi 











6 Click Next. 


7 Finish creating the bundle as usual. 
W] Success: The Bundle has been created successfully. 


Bundles 


& Newv < 
Category Enabled Version 





Status Name + Type 

















Ša P wse3 Windows Bundle MSI Application Yes 0 
4|>|1-10F1 


8 Repeat Step 1 through Step 7 until you have created the bundles that you need. 
9 Continue with Setting the Security Level for Each Bundle. 


28.2 Setting the Security Level for Each Bundle 


In ZENworks Control Center: 


1 Click a bundle name, then click the Actions tab. 


Bundles > WSE3 


& wse3 
Summary Relationships Requirements Actions Settings 


Distribute stall Hij 
Add + 


Name Type State Continue on Failure 


























Distribute Files Distribute Files Enabled 





show 5v items 





» |1-10F4 


Apply Reset 


2 Click the Install tab, then click Install MSI. 


254 GroupWise 8 Interoperability Guide 


L? |X, 


Edit Action - Install MSI 





Action Name: *|Install MSI 


msi File: * 


wse3.msi @ 


Select the parameters for msiexec, 
nstall Parameters: * 




















fiwse3.msi /qn fal 
Uninstall Parameters: E 
/xwse3.msi /qn El 
Repair Parameters: 

#wse3.msi fqn E 





3 Click More Options in the lower right corner of the dialog box. 





m Executable security level 
© Run as logged in user 
Display Mode: | Normal v 





C Grant administrator privilege to user during installation 
NING: Checking this option will add the user to the administrators group while the action is running. This 











may result in a password prompt and decreased security. 


O Run as secure systern user (Don't allow system to interact with desktop) 





O Run as dynamic administrator 








4 Set Executable security level to Run as dynamic administration, then click OK. 


5 Click Apply to save the setting. 
6 Repeat Step 1 through Step 5 for each bundle that you created. 


7 Continue with Configuring Each Bundle. 


28.3 Configuring Each Bundle 


In ZENworks Control Center: 


1 Assign each bundle to the appropriate GroupWise users. 
2 Create a launch schedule for each bundle so that the bundles launch in the following order: 


* wse3.msi 


+ msxml.msi 


* groupwise.msi 
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29.1 


Using ZENworks 7 Desktop Management 
to Distribute the GroupWise Windows 
Client 


You can use the Application Management functionality in Novell ZENworks 7 Desktop Management 
to distribute the GroupWise Windows client to workstations. 

¢ Section 29.1, “Installing Supporting Applications,” on page 257 

+ Section 29.2, “Creating a GroupWise Client Application Object,” on page 258 

¢ Section 29.3, “Using GroupWise 8 Tuner,” on page 261 

+ Section 29.4, “Configuring ZENworks to Use a Transform File,” on page 263 





IMPORTANT: This information assumes that you are familiar with ZENworks Desktop 
Management. For background information, or for help completing the ZENworks tasks outlined in 
the steps below, see the ZENworks Desktop Management documentation at the Novell ZENworks 
Documentation Web site (http://www.novell.com/documentation/zenworks7). 





Installing Supporting Applications 


Before you distribute the GroupWise Windows client software, the following files must be 
distributed to GroupWise users’ workstations: 

+ dotnetfx.exe (if .NET 2.0 or later is not already installed on workstations) 

* wse3.msi 


+ msxml.msi 
To prepare workstations for installation of the GroupWise Windows client: 


1 Create a NAL Application object for each file that you need to distribute: 


la In ConsoleOne, right-click the container where you want to create the NAL Application 
object, then click New > Object > Application. 


1b (Conditional) When you are creating the object for dotnet £x. exe, select A simple 
application, then click Next. 


or 


(Conditional) When you are creating the object for a .msi file, select An application that has 
an .MSI file. 


1c Click Next. 
1d Specify the path to the file, then click Next. 


le Specify the name for the NAL Application object, such as DOTNETFX, WSE3, MSXML, or 
GroupWise Windows Client, then click Next. 
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1f Finish creating each NAL Application object as usual. 
1g Repeat Step 1 for each file that you need to distribute. 
2 (Conditional) When you are installing dotnet £x. exe: 


2a Right-click the DOTNETFX NAL Application object that you created in Step 1b, then click 
Properties. 


2b Click the Run Options tab, then click Application. 
2c In the Parameters field, specify: 


/q:a /c:"install /q" 
2d Click OK. 
3 Select Force Cache for each NAL Application object. 
4 Assign each NAL Application object to the appropriate GroupWise users. 


5 Create a schedule for each NAL Application object so that the applications are installed in the 
following order: 


+ dotnetfx.exe 
* wse3.msi 
+ msxml.msi 


* groupwise.msi 


29.2 Creating a GroupWise Client Application Object 


The following steps explain how to use ZENworks Desktop Management to create a GroupWise 
client Application object from the .msi file. Depending on your version of ZENworks Desktop 
Management, the steps might be slightly different. If you want to change the default MSI installation, 
then you must use the GroupWise 8 Tuner program to create a custom transform file. For more 
information on how to use GroupWise 8 Tuner, see Section 29.3, “Using GroupWise 8 Tuner,” on 
page 261. 


1 In ConsoleOne, right-click the container where you want to create the GroupWise client 
Application object, then click New > Object to display the New Object dialog box. 


2 Inthe list of objects, click Application, then click OK to display the New Application dialog box. 


New Application Object 


Create an Application object for: 


CA simple application (no AOTLAXT/MSI file) 


C An application that has an .AOT/.AXT file 


C An application by using an existing Application object 


© A Web application 


CA Terminal Server application 


To continue, click Next. 





| Next > | Cancel | | Help | 
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3 Select An Application that Has an .msi File, then click Next to display the .msi file path page. 
New Application Object 


Specify the path to the MSI file you want to use to create the Application object. 


E Novel 
4 ZENworkse 7 


Path to MSI File: 
lu: \server|software\client\win32\groupwise msi El 





To continue, click Next. 





<= Back | Next = Cancel | | Help | 








4 Inthe Path to .msi File field, browse for and select the groupwise.msi file. 


5 Click Next to display the Application object information page, then customize the object name, 
source path, and target path information if necessary. 


New Application Object 


Define the following information for the Application object. 
Novelle 
E ZENworkse 7 Object Name: 
3 Groupise Client 





Administration Package Path: 
J\serverisoftware\clientiwin32 








To continue, click Next. 





«< Back | Next > | Cancel | | Help | 








Object Name: The name to be used for the Application object in eDirectory. You might want to 
use a descriptive name. 

Administration Package Path: The directory from which the GroupWise client will be installed. 
Specify the full path to the client directory (for example, 
\\serverl\vol1l\grpwise\software\client \win32). Unless all users will have the same drive 
mapping to the volume, make sure you use a UNC path. 


This path is saved as the Administration Package Path variable. If you need to change it later, 
you can do so on the Application object’s Sources page (Application object > Common > Sources). 


6 Click Next to display the rules to control availability of this application page, then modify the 
rules if necessary. 
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New Application Object 


Add rules to control availability of this application. 
Type Subject Operator 


d ZENworkse 7 








I Always show icon 


Add = Modify Delete 


To continue, click Next. 


<Back ||} Cancel i Helo | 





7 Click Next to display the user associations page. 


10 





New Application Object 


Add user and workstation associations: 


f oyen: voaa 


E ZENworkse 7 





Column Name: 


To continue, click Next. 


Add Delete 
<Back = |} Cancel i Help 





You can associate the Application object with the users and workstations you want the object 
distributed to at this time, or you can create the associations later. 


After you add the associations you want, click Next, review the information, then click Finish to 
create the Application object. 


Right-click the newly-created GroupWise client Application object, then click Properties. 


Configure any other Application object settings required to provide the performance or 
functionality you want. 


For example, you can configure the Application object so that the GroupWise client is installed 
immediately upon distribution to the user’s workstation, without any intervention by the user. 
Or, you can change the locations where the GroupWise client’s icon is displayed. Or, you can 
specify the location of a transform file for custom MSI installs. For information about 
Application object settings, see the ZENworks Desktop Management documentation at the 
Novell ZENworks Documentation Web site (http://www.novell.com/documentation-index/ 
index.jsp?category=ZENworks). 


GroupWise 8 Interoperability Guide 


29.3 


After you associate the Application objects with the users you want, Novell Application Launcher 
displays the Application object’s icon on the users’ workstations, if the workstation meets the 
operating system requirements. If the Application object’s icon does not appear immediately, have 
the user refresh Novell Application Launcher. 


If a service is preventing the GroupWise Windows client from installing correctly you can add a 
property to the GroupWise application object that stops the service until the installation has finished. 


1 In ConsoleOne, right-click the container where you created the GroupWise client Application 
object, then double-click the GroupWise Application object. 

2 Click MSI > Properties, then click Add. 

3 In the Value name field, type STOPSERVICE. 

4 Inthe Value Data field, type the name of the service to stop. 

5 Click OK twice. 


Using GroupWise 8 Tuner 


GroupWise 8 Tuner is an application that allows you to customize your MSI install. The Tuner 
application creates a transform file called groupwise.mst, which you can specify to use when 
performing an MSI install with ZENworks. You must have write access to the software distribution 
directory to use the GroupWise 8 Tuner application. 





NOTE: If you install the GroupWise client using a Tuner file to a protected area, such as the 
C:\Program Files directory, the installation fails if you try to install using a non-Administrator 
user. You must install the GroupWise client to an unprotected area such as, C: \Novel1\GroupWise if 
you are using a non-Administrator user. 





1 From the \admin\UTILITY\GWTUNER directory of the GroupWise 8 or greater download, select 
the GWTuner . exe file, then click OK to run the GroupWise 8 Tuner application. 


2 Specify the location of the client distribution directory on your GroupWise system, then click 
Next. 


GroupWise Install Tuner 


Welcome to the Groupwise Install Tuner. 
This program will help you create a Windows Installer 


Transform, which will allow you to apply modified settings 
to the GroupWise install. 


Please specify the location of the Client directory: 





wiz. 0.242007.03.12 multiwin_ nim release\client iim 








3 Specify where the GroupWise client should be installed on the client machines. 
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GroupWise Install Tuner 


General Settings 


Install path: 





[C:\Program Files\Novell\GroupWise 


Program folder: 





[Novell Groupwise 


IV Add Groupwise to the Desktop 
IV Add GroupWise to the Quick Launch 
| Add Notify to the Startup folder 


I Install Internet Browser Mail Integration 








Cancel 





Specify which program folder the GroupWise client should be installed to. 
Select if you want to add a GroupWise icon to the client desktop. 

Select if you want to add a GroupWise icon to the client Quick Launch. 
Select if you want to add GroupWise to the client Startup folder. 


Select if you want to install GroupWise Internet Browser Mail Integration. 


oOo ON Oo Ff 


Click Next to continue. 


10 Select the languages to install, then click Next. 


GroupWise Install Tuner 


Languages 
Select the languages you want to install: 


M] English 

O årabic 

O Brazilian Portugese 
O Chinese Simplified 
O Chinese Traditional 
O Czech 

O Danish 

O Dutch 

O Finnish 

(J French 

O German 

O Hebrew 

MI Hunaarian 














< Back Cancel 





11 Select the default startup language for the client, then click Next. 
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GroupWise Install Tuner 


Default Language 
Select the default startup language: 


English 











Cancel 





12 Select which software integration you want the client to use. 


GroupWise Install Tuner 


Software Integration 


Select the software you want to integrate with 
GroupWise: 





Corel Presentations 
Corel Quattro Pro 
Corel WordPerfect 
Microsoft Excel 
Microsoft PowerPoint 
Microsoft Word 














13 Click Finish to create the transform file (groupwise.mst) in the client software distribution 
directory. 


29.4 Configuring ZENworks to Use a Transform File 


After you have created the transform file (groupwise.mst), you must configure ZENworks to use the 
transform file when doing MSI installations. 


1 From ConsoleOne, right-click the application file that was created in Section 29, “Using 
ZENworks 7 Desktop Management to Distribute the GroupWise Windows Client,” on page 257, 
then click Properties. 


2 Click the MSI > Transform tab. 

3 Click Add, then browse to the location of the transform file (groupwise.mst). 
4 Click OK to add the transform file to the Transform List. 

5 Click OK again. 
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3 


Using ZENworks Linux Management to 
Distribute the GroupWise Linux/Mac 
Client 


You can install the GroupWise Linux/Mac client and agents using Novell ZENworks Linux 
Management or later. Refer to the Novell ZENworks Linux Management (http://www.novell.com/ 
products/zenworks/linuxmanagement/) site for additional information. 
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ZENworks Application Virtualization for 
GroupWise and Messenger 


Novell ZENworks Application Virtualization lets you convert applications that run on Microsoft 
Windows into self-contained virtual applications. After being virtualized, an application becomes a 
single, isolated file that runs instantly from anywhere, including a thumb drive or other removable 
media. Unlike traditional installation methods, the single virtual application file does not require a 
separate setup process, and does not rely on external components and runtimes, reboots, or 
administrative privileges. After virtualization, the application is isolated from other system 
applications, preventing DLL conflicts and other deployment nightmares, yet the experience for the 
application’s user is unchanged. 


For instructions on virtualizing the GroupWise Windows client, see “Preparing GroupWise and 
GroupWise Notify for Virtualization” in the ZENworks Integration Guide (http://www.novell.com/ 
documentation/zav61/zav61_integration/data/index.html). 


For instructions on virtualizing the Messenger Windows client, see “Preparing Novell Messenger for 
Virtualization” in the ZENworks Integration Guide (http://www.novell.com/documentation/zav61/ 
zav61_integration/data/index.html). 
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VI Other Novell Products 


+ Chapter 32, “GroupWise DirXML Driver for Novell Identity Manager,” on page 271 
¢ Chapter 33, “GroupWise Customization Tools,” on page 275 
¢ Chapter 34, “Novell exteNd,” on page 277 
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32.1 


GroupWise DirXML Driver for Novell 
Identity Manager 


The GroupWise DirXML driver for use with Novell Identity Manager provides data integration 
between users in Novell eDirectory with GroupWise accounts in your GroupWise system. For 
example, the driver can create e-mail accounts automatically when employees are hired. The driver 
can also disable an e-mail account when a user is no longer active. This configurable solution gives 
you the ability to increase productivity and streamline business processes by integrating GroupWise 
and eDirectory. 


This guide gives information about certain administrative actions in ConsoleOne that require you to 
stop the GroupWise DirXML driver or disable a user’s association: 


+ Section 32.1, “Identity Manager Warnings in ConsoleOne,” on page 271 
For additional information, see: 


+ Novell Identity Manager (http://www.novell.com/documentation/idm36) 


¢ Identity Manager Drivers (http://www.novell.com/documentation/idm3édrivers) 


Identity Manager Warnings in ConsoleOne 


Some GroupWise administrative actions in ConsoleOne require that you stop the GroupWise 
DirXML driver or disable a user’s association with it before you perform the action and usually 
restart the GroupWise DirXML driver or re-enable the user’s association when you have completed 
the action. By default, these activities generate a warning message in ConsoleOne: 

+ Section 32.1.1, “Recovering a Deleted GroupWise Account,” on page 272 

+ Section 32.1.2, “Grafting Users,” on page 272 

+ Section 32.1.3, “Converting an External Entity to a User,” on page 272 

è Section 32.1.4, “Converting a User to an External Entity,” on page 272 

è Section 32.1.5, “Associating a GroupWise Object with an eDirectory Object,” on page 272 


è Section 32.1.6, “Disassociating a GroupWise Object’s Attributes from an eDirectory Object,” on 
page 273 


è Section 32.1.7, “Resolving an Invalid Association,” on page 273 
¢ Section 32.1.8, “Disabling the DirXML Warnings,” on page 273 
è Section 32.1.9, “Enabling the DirxXML Warnings,” on page 273 
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32.1.1 Recovering a Deleted GroupWise Account 


1 Using the DirXML Management role in Novell iManager, stop the GroupWise DirXML driver. 


2 Recover the deleted account, as described in “Recovering Deleted GroupWise Accounts” in 
“Databases” in the GroupWise 8 Administration Guide. 


3 Using the DirxML Management role, restart the GroupWise DirXML driver. 


32.1.2 Grafting Users 


1 If you are grafting the users into a different eDirectory tree, on the DirXML tab of each User 
object in Novell iManager, disable the association with the GroupWise DirXML driver. 


2 Using the DirxXML Management role in Novell iManager, stop the GroupWise DirXML driver 
for the tree into which you are grafting the users. 


3 Graft the users, as described in “Graft GroupWise Objects” in “Databases” in the GroupWise 8 
Administration Guide. 


4 If you grafted the users into a different eDirectory tree, on the DirXML tab of each User object, 
enable the association with the GroupWise DirXML driver in the new tree. 


5 Using the DirxML Management role, restart the GroupWise DirXML driver for the tree into 
which you grafted the users. 


32.1.3 Converting an External Entity to a User 


1 Using the DirXML Management role in Novell iManager, stop the GroupWise DirXML driver. 


2 Convert the external entity, as described in “Convert External Entity to User” in “System” in the 
GroupWise 8 Administration Guide. 


3 Using the DirxXML Management role, restart the GroupWise DirXML driver. 


32.1.4 Converting a User to an External Entity 
1 On the DirXML tab of the User object in Novell iManager, disable the association with the 
GroupWise DirXML driver. 


2 Convert the user, as described in “Convert User to External Entity” in “System” in the GroupWise 
8 Administration Guide. 


32.1.5 Associating a GroupWise Object with an eDirectory Object 


1 Using the DirXML Management role in Novell iManager, stop the GroupWise DirXML driver. 


2 Establish the association, as described in “Associate Objects” in “System” in the GroupWise 8 
Administration Guide. 


3 Using the DirxML Management role, restart the GroupWise DirXML driver. 
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32.1.6 


32.1.7 


32.1.8 


32.1.9 


Disassociating a GroupWise Object’s Attributes from an eDirectory 
Object 


1 On the DirXML tab of the User object in Novell iManager, disable the association with the 
GroupWise DirXML driver. 


2 Disassociate the objects, as described in “Disassociate GroupWise Attributes” in “System” in the 
GroupWise 8 Administration Guide. 


3 On the DirXML tab of the User object, enable the association with the GroupWise DirXML 
driver. 


Resolving an Invalid Association 


1 On the DirXML tab of the User object in Novell iManager, disable the association with the 
GroupWise DirXML driver. 


2 Resolve the invalid association, as described in “Invalid Associations” in “System” in the 
GroupWise 8 Administration Guide. 


Disabling the DirXML Warnings 


1 In ConsoleOne, deselect Display DirXML Warnings in any DirXML warning dialog box. 


Enabling the DirXML Warnings 


1 In ConsoleOne, click Tools > GroupWise System Operations > System Preferences. 
2 On the Admin Preferences tab, select Display DirXML Warnings. 
3 Click OK. 
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3 GroupWise Customization Tools 


The GroupWise Software Developer Kit provides tools for customizing GroupWise to the specific 
needs of your organization. It includes the following components: 


+ 


WebAccess Customization: Lets you modify the WebAccess client HTML source files to include 
your own graphics or company information. You can also enhance the WebAccess client by 
creating additional calendar views. For more information, see GroupWise WebAccess 
Customization (http://developer.novell.com/wiki/index.php/ 
GroupWise_WebAccess_Customization). 


GroupWise Object API: Lets you create your own client application. It provides access to the 
Address Book, along with documents, mail messages, appointments, tasks, notes, phone 
messages, and workflow items. The GroupWise Object API supports COM Automation, which 
is an industry standard for interfacing applications and is simple to use with languages such as 
Delphi, Visual Basic, and C+. For more information, see GroupWise Object API (http:// 
developer.novell.com/wiki/index.php/GroupWise_Object_API). 


GroupWise Administrative Object API: Lets you see, use, and manipulate GroupWise 
administration information from outside GroupWise. You can use the GroupWise 
Administrative Object API through COM languages, such as Visual Basic, Delphi, and object- 
oriented languages (such as C++). It also supports COM Automation, which is an industry 
standard for interfacing applications. For more information, see GroupWise Administrative 
Object API (http://developer.novell.com/wiki/index.php/ 
GroupWise_Administrative_Object_API). 


GroupWise C3PO (Custom 3rd-Party Object): Works with C++, Delphi, or Visual Basic to let 
you add menu and toolbar items to trigger applications. For example, you can modify the 
GroupWise client toolbar or define new record types in the GroupWise information store. For 
more information, see GroupWise C3PO (http://developer.novell.com/wiki/index.php/ 
GroupWise_C3PO). 


GroupWise Tokens: Let you manipulate the GroupWise client interface by subscribing to 
internal token events or by publishing new tokens to the client. It names low-level events, such 
as “save a file” or “send mail,” which allows you to extend GroupWise functionality. A C3PO 
lets you extend GroupWise objects and the Object API lets you see and manipulate the 
GroupWise information store from outside GroupWise. In addition, tokens let your solution 
command the GroupWise client from DLLs and DDE scripts, using the Third-Party Handler. 
You can also use tokens to create Visual Basic executables that users can run from the client 
interface. For more information, see GroupWise Tokens (http://developer.novell.com/wiki/ 
index.php/GroupWise_Tokens). 


GroupWise Trusted Applications: Enables you to develop applications that can log in to any 
user’s mailbox without supplying the user’s password and perform various tasks such as virus 
scanning, content filtering, or e-mail auditing. For more information, see GroupWise Trusted 
Application API (http://developer.novell.com/wiki/index.php/ 
GroupWise_Trusted_Application_API). 


GroupWise SOAP: Provides access to GroupWise data, through defined standards, directly 
from the GroupWise post office. The standards used include: HTTP, SOAP, XML, XML schemas, 
and WSDL. HTTP, SOAP, and XML are used to transport data from between computers. XML 
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schemas define the structure and the types of GroupWise data that is transported. The 
GroupWise WSDL (Service Descriptive Language) combines everything into a GroupWise Web 
service. For more information, see GroupWise Web Service (SOAP) (http:// 
developer.novell.com/wiki/index.php/GroupWise_Web_Service_%28SOAP%29). 


GroupWise MAPI: Uses a set of object-oriented functions that provide messaging capabilities. 
The Messaging Application Programming Interface (MAPI) is used by mail-enabled 
applications to create, transfer, and store messages, as well as to handle complex addressing 
information. MAPI objects are data structures that support a set of properties and that comply 
with the component object model (which requires that objects support one or more interfaces or 
sets of functions). For more information, see GroupWise MAPI (http://developer.novell.com/ 
wiki/index.php/GroupWise_MAPI). 


GroupWise Events: Provides event notification to registered third-party applications, and is 
responsive to queries, while not significantly degrading the overall performance of the 
GroupWise Post Office Agent (POA). This functionality is included in the GroupWise Object 
API (http://developer.novell.com/wiki/index.php/GroupWise_Object_API). 


GroupWise Controls for ActiveX: Lets you embed an Address Book or Name Completion COM 
Control (OCX) in your Visual Basic, Delphi, and C++ solutions. OCX properties let you 
customize user access to Address Book contents and control return information for your 
solution to use. For more information, see GroupWise Controls for ActiveX (http:// 
developer.novell.com/wiki/index.php/GroupWise_Controls_for_ActiveX). 
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Novell exteNd 


In different versions of GroupWise, WebAccess has stored its default user interface files in different 
directories on the Web server: 


GroupWise 6.5: 


tomcat_root/webapps/gw/WEB-INF/classes/com/novell/webaccess/templates/frames 


GroupWise 7: 


tomcat_root/webapps/gw/WEB-INF/classes/com/novell/webaccess/templates/css 


GroupWise 8: 





tomcat_root/webapps/gw/WEB-INF/classes/templates/webacc/css 


If you have exteNd portlets configured to use WebAccess, you must copy some of the exteNd 
template files from the previous directory into the GroupWise 8 css directory. Refer to the Identity 
Manager Accessory Portlet Reference Guide (http://developer.novell.com/wiki/index.php/ 
GroupWise_Controls_for_ActiveX) to determine which exteNd template files you should copy to the 
css directory. Do not copy the entire contents of the previous directory into the GroupWise 8 css 
directory; this would damage the new GroupWise 8 WebAccess user interface. 


If you are updating from GroupWise 6.5 to GroupWise 8, modify the WebAccess URL in the exteNd 
Portal Preferences from: 


http://web_server_address/servlet/webacc 


to: 


http://web_server_address/gw/webacc 
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VI Microsoft Clustering Services on 
Windows 


¢ Chapter 35, “Introduction to GroupWise 8 and Microsoft Clusters,” on page 281 

+ Chapter 36, “Planning GroupWise in a Microsoft Cluster,” on page 283 

¢ Chapter 37, “Setting Up a Domain and Post Office in a Microsoft Cluster,” on page 299 
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Introduction to GroupWise 8 and 
Microsoft Clusters 


Before implementing GroupWise 8 in a Microsoft cluster, make sure you have a solid understanding 
of Microsoft clustering technologies by reviewing the following information resources: 


e Windows Server 2008 — High Availability (http://www.microsoft.com/windowsserver2008/en/ 
us/high-availability.aspx) 

+ Windows Server 2003 — Server Cluster (http://www.microsoft.com/windowsserver2003/ 
technologies/clustering/default.mspx) 


When you review the information resources recommended above, you discover that clustering 
employs very specialized terminology. The following brief glossary provides basic definitions of 
clustering terms and relates them to your GroupWise system: 


cluster: A grouping of from two to eight Windows servers configured so that data storage locations 
and applications can transfer from one server to another without interrupting their availability to 
users. 


node: A clustered server; in other words, a single Windows server that is part of a cluster. 


active node: A node in the cluster that is actively running programs. An active node makes its 
resources available in the cluster. 


passive node: A node in the cluster that is not currently running programs, but is waiting for an 
active node to fail. A passive node does not make its resources available in the cluster until an active 
node fails over to it. 


resource: A data storage location or application. For example, a domain directory and the MTA for 
the domain are resources. A post office directory and the POA for the post office are resources. 


resource group: Two or more resources that must fail over together in order to remain functional. For 
example, for a domain to be functional, the domain directory and its MTA must fail over together. For 
a post office to be functional, the post office directory and its POA must fail over together 


physical disk: The physical location where resources are created or installed. For example, a domain 
or post office directory is created on a physical disk. The agent software is installed on a physical 
disk. 


shared disk: A physical disk that can be made active on any node in the cluster. 


failover: The process of moving resources and resource groups ona shared disk from a failed node to 
a functional node so that availability to users is uninterrupted. For example, if the node where the 
POA is running goes down, the post office resource group would fail over to another node so that 
users could continue to use GroupWise. 
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fan-out-failover: The configuration where resources and resource groups from a failed node fail over 
to different nodes in order to distribute the load from the failed node across multiple nodes in the 
cluster. For example, if a node runs a resource group consisting of a domain and its MTA, another 
resource group consisting of a post office and its POA, and a third resource group for WebAccess, 
each resource group could be configured to fail over separately to different nodes in the cluster. 


failback: The process of returning resources and resource groups to their original node after the 
situation causing the failover has been resolved. For example, if a POA and its post office fail over to 
another node in the cluster, that resource group can be configured to fail back to its original node 
when the problem is resolved. 


shared disk system: The hardware housing the physical disks that are shared among the nodes in the 
cluster. The C: drives in the clustered nodes are not part of the shared disk system. Each C: drive 
belongs to its own server. 


storage area network (SAN): The clustered nodes together with their shared disk system and shared 
physical disks. 
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Planning GroupWise in a Microsoft 
Cluster 


The majority of this part of the guide (Chapter 36, “Planning GroupWise in a Microsoft Cluster,” on 
page 283 through Chapter 42, “Backing Up a GroupWise System in a Microsoft Cluster,” on 

page 335) is designed for those who are creating a new GroupWise system, or at least new domains 
and post offices, in a Microsoft cluster. If you already have an existing GroupWise 6.x system and 
need to configure it to work in a newly installed cluster, see Chapter 43, “Moving an Existing 
GroupWise 8 System into a Microsoft Cluster,” on page 337. 


When you implement a new GroupWise system or anew domain or post office in a Microsoft cluster, 
overall GroupWise system design does not need to change substantially. For a review, see “Installing 
a Basic GroupWise System” in the GroupWise 8 Installation Guide. However, the configuration of 
individual components of your GroupWise system will be significantly different. This section helps 
you plan the following GroupWise components in a Microsoft cluster: 

+ Anew GroupWise system consisting of the primary domain and the initial post office 

+ Anew secondary domain 

+ Anew post office 

+ The GroupWise agents (MTA and POA) 
During the planning process, component configuration alternatives are explained. For example, you 
might want the domain and post office together in the same resource group or in separate resource 
groups. You might want to install the agents to the standard c: \grpwise directory on each node or to 


manually create a drive: \grpwise directory for each shared disk for domains and post offices so 
that the agents fail over with the domains and post offices they service. 


The “System Clustering Worksheet” on page 294 lists all the information you need as you set up 
GroupWise in a Microsoft cluster. You should print the worksheet and fill it out as you complete the 
tasks listed below: 

+ Section 36.1, “Setting Up Your Microsoft Cluster,” on page 284 

+ Section 36.2, “Planning a New Clustered Domain,” on page 285 

+ Section 36.3, “Planning a New Clustered Post Office,” on page 285 

+ Section 36.4, “Planning a New Library for a Clustered Post Office,” on page 286 

+ Section 36.5, “Planning GroupWise Resource Groups,” on page 286 

+ Section 36.6, “Planning Shared Administrative Resources,” on page 287 


¢ Section 36.7, “Ensuring Successful Name Resolution for GroupWise Resource Groups,” on 
page 287 


+ Section 36.8, “Deciding How to Install and Configure the Agents in a Cluster,” on page 289 
+ Section 36.9, “GroupWise Clustering Worksheets,” on page 294 
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After you have completed the tasks and filled out the “System Clustering Worksheet” on page 294, 
you are ready to continue with Chapter 37, “Setting Up a Domain and Post Office in a Microsoft 
Cluster,” on page 299. 


Setting Up Your Microsoft Cluster 


As you set up your Microsoft cluster, record key information about the cluster on the System 
Clustering Worksheet: 


SYSTEM CLUSTERING WORKSHEET 


Under Item 1: Cluster Name, record the name of your Microsoft cluster. 


Under Item 2: Nodes in Cluster, list the servers that you have added to the cluster. 


The number of nodes in the cluster strongly influences where you place GroupWise domains and 
post offices. You have several alternatives: 


e Your whole GroupWise system can run in a single cluster. 


+ Parts of your GroupWise system can run in one cluster while other parts of it run in one or more 
other clusters. 


¢ Parts of your GroupWise system can run in a cluster while other parts run outside of the cluster, 
on non-clustered servers. 


If you do not have the system resources to run all of your GroupWise system in the cluster, you must 
decide which parts have the most urgent need for the high availability provided by clustering. Here 
are some suggestions: 


+ Post offices and their POAs must be available in order for users to access their GroupWise 
mailboxes. Therefore, post offices and their POAs are excellent candidates for the high 
availability provided in a cluster. 


+ Ina like manner, WebAccess provides user access to GroupWise mailboxes across the Internet 
through users’ Web browsers. It is another good candidate for the cluster. 


+ Domains and their MTAs are less noticeable to GroupWise client users when they are 
unavailable (unless users in different post offices happen to be actively engaged in an e-mail 
discussion when the MTA goes down). On the other hand, domains and their MTAs are critical 
to GroupWise administrators, although administrators might be more tolerant of a down server 
than client users are. Critical domains in your GroupWise system are the primary domain and, if 
you have one, a hub or routing domain. These domains should be in the cluster, even if other 
domains are not. 


¢ The Internet Agent might or might not require high availability in your GroupWise system, 
depending on the importance of immediate messaging across the Internet and the use of POP3 
or IMAP4 clients by GroupWise users. 


There is no right or wrong way to implement GroupWise in a cluster. It all depends on the specific 
needs of your particular GroupWise system and its users. 
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Planning a New Clustered Domain 


The considerations involved in planning anew domain in a Microsoft cluster are essentially the same 
as for any other environment. 


+ Primary Domain: If you are setting up anew GroupWise system in a Microsoft cluster, you will 
be creating the primary domain as you complete the tasks in this section. In preparation, review 
“Planning a Basic GroupWise System”, then print and fill out the “Basic GroupWise System 
Summary Sheet” in “Installing a Basic GroupWise System” in the GroupWise 8 Installation Guide. 
This covers planning the primary domain and an initial post office in the primary domain. 


+ Secondary Domain: If your GroupWise system already exists, you will be creating a new 
secondary domain. In preparation, review “Planning a New Domain’, then print and fill out the 
“Domain Worksheet” in “Domains” in the GroupWise 8 Administration Guide. 


Regardless of the type of domain you are creating, keep in mind the following cluster-specific details 
as you fill out the worksheet you need: 


+ When you specify the location for the domain directory (and for a new GroupWise system, the 
post office directory) on the worksheet, include the shared disk where you want the directory to 
reside. 


+ Do not concern yourself with the GroupWise agent information on the worksheet. You will plan 
the agent installation later. If you are filling out the Basic GroupWise System Worksheet, stop 
with Post Office Settings. If you are filling out the Domain Worksheet, stop with Domain 
Administrator. 


When you have completed the worksheet, transfer the key information from the Basic GroupWise 
System Worksheet or the Domain Worksheet to the System Clustering Worksheet. 
SYSTEM CLUSTERING WORKSHEET 


Under Item 7: Domain Name, transfer the domain name and directory to the System Clustering 
Worksheet. 





IMPORTANT: Do not create the new domain until you are instructed to do so in Chapter 37, “Setting 
Up a Domain and Post Office in a Microsoft Cluster,” on page 299. 





Planning a New Clustered Post Office 


The considerations involved in planning a new post office in a Microsoft cluster are essentially the 
same as for any other environment. The initial post office in a new GroupWise system is planned on 
the Basic GroupWise System Worksheet. To plan additional new post offices, review “Planning a 
New Post Office ”, then print and fill out the “Post Office Worksheet” in “Post Offices” in the 
GroupWise 8 Administration Guide. When you specify the locations for the post office directories, 
include the shared disks where you want the post office directories to reside. 


When you have completed the worksheet, transfer key information from the Basic GroupWise 
System Worksheet or the Post Office Worksheet to the System Clustering Worksheet. 


SYSTEM CLUSTERING WORKSHEET 


Under Item 8: Post Office Name, transfer the post office name and directory to the System Clustering 
Worksheet. 
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IMPORTANT: Do not create the new post office until you are instructed to do so in Chapter 37, 
“Setting Up a Domain and Post Office in a Microsoft Cluster,” on page 299. 





Planning a New Library for a Clustered Post Office 


The considerations involved in planning a library in a Microsoft cluster are essentially the same as for 
any other environment. You can plan a library for a new clustered post office by following the 
standard instructions provided in “Creating and Managing Libraries” in the GroupWise 8 
Administration Guide and filling out the “Basic Library Worksheet” or the “Full-Service Library 
Worksheet”. Then provide the library information on the System Clustering Worksheet. 


SYSTEM CLUSTERING WORKSHEET 


Under Item 9: Document Storage Area Location, mark where you want to create the library’s 
document storage area. 


If the document storage area will be located outside the post office directory structure and outside the 
cluster, specify a user name and password that the POA can use to access the server where the 
document storage area will reside. 





IMPORTANT: Do not create the new library until you are instructed to do so in Chapter 37, “Setting 
Up a Domain and Post Office in a Microsoft Cluster,” on page 299. 





Planning GroupWise Resource Groups 


Resource groups ensure that resources that depend on each other fail over together. If your 
GroupWise system is very small (for example, one domain and one post office), you could have a 
single GroupWise resource group so that your whole GroupWise system would fail over together. 
More typically, multiple domains and post offices are located throughout your organization, so you 
would set up a resource group for each domain and post office. 


A resource group for a domain or post office must include the following types of resources: 


+ Network Name: The virtual name by which the domain or post office resource group will be 
known on the network, regardless of which node it is active on 


+ IP Address: The virtual IP address that will be associated with the network name, regardless of 
which node the domain or post office resource group is active on 


¢ Physical Disk: The drive letter where the domain or post office directory will be located, used 
when mapping a drive to the physical disk 


¢ File Share: The name of the physical disk, used when mapping a drive to the physical disk 


+ Generic Service: The GroupWise agent, running as a Windows service, that will service the 
domain or post office 


For convenience, you might want to name each resource group after the domain or post office it 
represents. In this documentation, a resource group that could include a domain, a post office, or 
both, is termed a “GroupWise resource group.” 


Each GroupWise resource group has associated with it a list of possible owners. The possible owners 
are the nodes to which the resource group could fail over. By default, a resource group is configured 
to have all nodes in the cluster in its possible owners list, organized in ascending alphanumeric order. 
Only one node at a time can have a particular GroupWise resource group active. If a resource group’s 
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current owner node fails, the resource group fails over to the next node in the possible owners list. 
You should customize the owners list for each GroupWise resource group based on the fan-out- 
failover principle. 


When a node fails, its resource groups should not all fail over together to the same node in the cluster. 
Instead, the resource groups should be distributed across multiple nodes throughout the cluster. This 
prevents any one node from shouldering the entire processing load typically carried by another 
node. In addition, some GroupWise resource groups should never have the potential of failing over 
to the same node. For example, a post office and POA that service a large number of very active 
GroupWise client users should never fail over to a node where another very large post office and 
heavily loaded POA reside. If they did, users on both post offices would notice a decrease in 
responsiveness of the GroupWise client. 





IMPORTANT: If you are planning more than one Internet Agent or WebAccess Agent in the cluster, 
you must ensure that they can never fail over to the same node at the same time. You cannot 
customize the Windows service names for the Internet Agent or the WebAccess Agent. Therefore, 
only one of each can run on a server. The Windows service names for POAs and MTAs include the 
name of the post office or domain that they service, so this limitation does not apply to POAs and 
MTAs. 





SYSTEM CLUSTERING WORKSHEET 


Under Item 4: Resource Group for Domain, specify the network name and other required information 
for the domain resource group. Mark whether you will place the post office in the same resource 
group with the domain. 


If you want the post office in a different resource group from where the domain is located, under Item 
5: Resource Group for Post Office, specify the network name and other required information for the 
post office resource group. 


Planning Shared Administrative Resources 


Depending on your administrative needs, you might or might not want to set up shared 
administrative resources. For example, you might want to have a shared disk where you install the 
GroupWise snap-ins to ConsoleOne instead of installing them on multiple administrator 
workstations. You might also have a shared disk where you create the GroupWise software 
distribution directory. These shared disks could be configured to fail over as part of your clustered 
environment. 


SYSTEM CLUSTERING WORKSHEET 


Under Item 3: Resources for GroupWise Administration, list any shared disks you want to use for 
GroupWise administration purposes. 


Ensuring Successful Name Resolution for GroupWise 
Resource Groups 


When you establish GroupWise resource groups, you establish network names for the locations of 
domains and post offices. The network names remain constant no matter which node in the cluster 
the domain or post office is currently active on. Because you are using virtual network names, not 
physical locations, you must ensure that short name resolution is always successful. For example, in 
ConsoleOne, if you right-click a Domain object in the GroupWise View and then click Connect, 
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ConsoleOne must be able to resolve the domain database location, as provided in the UNC Path field, 
to the network name of that domain within your cluster. It is through short name resolution that all 
GroupWise resource groups are accessed and managed in ConsoleOne. 


A client program (such as ConsoleOne) that runs on a Windows workstation, can be configured to 
use several different short name resolution methods. To see which methods are in use at a particular 
workstation, view the protocol preferences for the Novell Client that is installed on the Windows 
workstation: 


Figure 36-1 Novell Client Preferences Property Page 


Novell Client for Windows 2000 Properties a 2| x] 


Single Sign-on | DHCP Settings | Default Capture | 
Advanced Settings | Advanced Menu Settings | 
Client | Location Profiles | Advanced Login | Contextless Login | 
Protocol Preferences | Service Location | 









Select a protocol and component to configure 
Preferred Network Protocol: z 


Protocol: Component: 


A 


r- Protocol component settings ] 
MINDS 
E Host File 
DNS 
SLP 

O DHCP NDS 










Cancel 





Short name resolution methods that pertain to your clustered GroupWise system are discussed 
below: 


Table 36-1 Short Name Resolution Methods 


Short 

Name 

Resolutio Description 
n 

Method 


eDirector You can use Novell eDirectory to resolve short names into specific network addresses. 

y However, when using eDirectory for short name resolution, you must remember to 
consider current context in the name resolution process. eDirectory short name resolution 
works only if your current context is the same as the context of the eDirectory object you 
need to access. 


Hosts Windows XP/Vista uses the \winnt\system32\drivers\etc\hosts file when 
File performing short name resolution at the workstation: 


Using this file at the Windows workstation is not a preferred method for short name 
resolution (except perhaps for the administrator’s workstation). 
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Short 
Name 
Resolutio Description 


n 
Method 


DNS Perhaps the most common short name resolution option is Domain Name Service (DNS). 
As with the hosts file, it is good practice to place all the network names of your 
GroupWise resource groups into DNS. 


For short name resolution to work using DNS, the client workstation must either belong to 
the same DNS zone (such as support.novell.com) as the resource group, or the cluster 
resource zone must be configured in the client's DNS suffix search path under TCP/IP 
settings for the workstation. 


Specific setup instructions for each of these short name resolution methods are provided in 
Chapter 37, “Setting Up a Domain and Post Office in a Microsoft Cluster,” on page 299. 


SYSTEM CLUSTERING WORKSHEET 


Under Item 6: IP Address Resolution Methods, mark which methods you want to implement in order 
to resolve the locations stored as UNC paths in ConsoleOne into the network names of the 
GroupWise resource groups. 


36.8 Deciding How to Install and Configure the Agents ina 
Cluster 


There are several cluster-specific issues to consider as you plan to install the Windows MTA and POA 
in your clustered GroupWise system: 


+ Section 36.8.1, “Planning Cluster-Unique Port Numbers for Agents in the Cluster,” on page 289 
+ Section 36.8.2, “Deciding Where to Install the Agent Software,” on page 291 

+ Section 36.8.3, “Planning the Agent Services,” on page 293 

* Section 36.8.4, “Planning the Windows Agent Installation,” on page 293 


36.8.1 Planning Cluster-Unique Port Numbers for Agents in the Cluster 


By default, the GroupWise agents listen on all IP addresses, both primary and secondary, that are 
bound to the server on their specified port numbers. The primary IP address is the IP address of the 
physical node. Secondary IP addresses are the IP addresses associated with GroupWise resource 
groups. 


Any time there is a possibility of two of the same type of agent running on the same node, it is 
important that each agent use a cluster-unique port number, even though each agent is using the 
unique IP address established for each GroupWise resource group. The best way for you to avoid 
port conflicts is to plan your cluster so that each agent in the cluster runs on a cluster-unique port. 
Print out a copy of the “Network Address Worksheet” on page 296 to help you plan cluster-unique 
port numbers for all GroupWise agents in your GroupWise system. 


The following filled-out version of the Network Address Worksheet illustrates one way this can be 
done: 
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Domain Information 


Domain MTA MTA MTA 
IP Address MTP Port HTTP Port 
Provo1 172.16.5.81 7100 7180 


Post Office Information 


Post Office POA POA POA POA 

IP Address CIS Port MTP Port HTTP Port 
Development (same as MTA) 1677 7101 7181 
Manufacturing 172.16.5.82 1678 7102 7182 


Internet Agent Information 


MTA 

GWIA MTA MTA Live GWIA 
Internet Agent IP Address MTP Port Remote Port Di HTTP Port 
GWIA Domain 172.16.5.83 7110 7677 7183 N/A 
MTA 
Internet Agent (same as MTA) N/A N/A N/A 9850 
(GWIA) 
WebAccess Information 

MTA 

WebAccess WebAccess MTA HTTP WebAccess WebAccess 
Agent IP Address MTP Port Port Agent Port HTTP Port 
WebAccess 172.16.5.84 7120 7184 N/A N/A 
Domain MTA 
WebAccess Agent (same as MTA) N/A N/A 7205 7205 
(GWINTER) (same as agent) 


This example places the Development post office in the same resource group with the Provo1 
domain; therefore, the Provol MTA and the Development POA use the same IP address. The 
Manufacturing post office is placed in a different resource group, so the Manufacturing post office 
has a different IP address. The Internet Agent and the WebAccess Agent each have their own 
domains and separate resource groups. 


The example also illustrates that the MTA, the POA, and the Internet Agent use different port 
numbers for agent ports and HTTP ports. In contrast, the WebAccess Agent uses the same port 
number for the agent port and the HTTP port. 
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The example uses default port numbers where possible. For example, the default MTA message 
transfer port is 7100 and the default POA client/server port is 1677. Incrementing port numbers are 
used in the example when multiple components have the same type of ports. For example, port 
numbers 1677 and 1678 are both POA client/server ports and port numbers 7180 through 7184 are all 
HTTP ports. Incrementing from the default port numbers generates unique, though related, port 
numbers. 


If you are going to set up a GroupWise name server to help GroupWise clients locate their post 
offices, make sure that the default POA port number of 1677 is used somewhere in the cluster and 
specify the IP address of the post office resource group, not the IP address of a specific node. For 
more information, see “Simplifying Client/Server Access with a GroupWise Name Server” in “Post 
Office Agent” in the GroupWise 8 Administration Guide. 


NETWORK ADDRESS WORKSHEET 


Fill out the “Network Address Worksheet” on page 296 to help you determine resource group IP 
addresses and cluster-unique port numbers for all GroupWise agents in the cluster. (MTA, POA, 
Internet Agent, WebAccess Agent). Refer to the IP addresses you planned for the domain and post 
office resource groups under items 4 and 5 on the System Clustering Worksheet. 


After you have filled out the Network Address Worksheet, transfer the IP addresses and the cluster- 
unique port numbers from the Network Address Worksheet to the Agent Clustering Worksheet so 
that they will be available in the sequence in which you will need them as you set up the GroupWise 
agents in the cluster. 


AGENT CLUSTERING WORKSHEET 


Under Item 4: MTA Network Information, transfer the resource group IP address and cluster-unique 
port numbers for the MTA from the Network Address Worksheet to the Agent Clustering Worksheet. 


Under Item 7: POA Network Information, transfer the resource group IP address and cluster-unique 
port numbers for the POA from the Network Address Worksheet to the Agent Clustering Worksheet. 


Deciding Where to Install the Agent Software 


In a Microsoft cluster, the agents must run as Windows services. When you install the Windows MTA 
and POA, you can choose between two different installation locations: 


Table 36-2 Agent Software Installation Locations 


Location Description 

Each node in the The c:\grpwise directory is the default location provided by the Agent 
cluster Installation program. 

Shared disk If you create a drive: \grpwise directory on the same shared disk with the 


domain or post office directory, the agent software and startup files fail over and 
back with the domains and post offices that the agents service. 


Because the agents must be installed as Windows services in a Microsoft cluster, you must initially 
run the Agent Installation program for each node in the cluster so that the Windows services for the 
agents get created, regardless of where you are planning to run the agents from. However, for 
updates, you need to run the Agent Installation program only once if you are running the agents 
from a shared disk. 
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The following sections can help you choose which installation location would be best for your 
clustered GroupWise system: 


+ “Advantages of Installing to a Shared Disk” on page 292 
¢ “Disadvantages of Installing to a Shared Disk” on page 292 


+ “Recommendation” on page 292 


Advantages of Installing to a Shared Disk 


Using a drive: \grpwise directory for each GroupWise shared disk has several advantages: 


¢ When you update the agent software, you only need to update it in one place for a particular 
domain or post office, not on every node in the resource group’s possible owners list. This 
prevents the potential problem of having a domain or post office fail over to a node where a 
different version of the agent software is installed. 


¢ Having the agent startup files on the same node as the domain or post office makes them easy to 
find. 


+ If you change information in the agent startup files, you only need to change it in one place, not 
on every node in the resource group’s possible owners list. 


¢ If you want to back up the GroupWise data, you can back up the domain and/or post office 
directories and the agent software from the same shared disk. 


Disadvantages of Installing to a Shared Disk 


Installing the agents on the same shared disk with a domain or post office does have some 
disadvantages: 


¢ You must install the agent software each time you create a new domain or post office on a new 
shared disk. 


+ GroupWise administrators who are used to the GroupWise agents being installed in 
c:\grpwise might be confused by not finding them there in the clustered GroupWise system. 


+ You must remember where you installed the GroupWise agents when you update the agent 
software. Accidently installing a GroupWise Support Pack to the default location of c:\grpwise 
on the active node would not have the desired results if the original agent software was installed 
to a shared disk. 


Recommendation 


Whichever method you choose, be consistent throughout the entire cluster. Either put all the 
GroupWise agents on the shared disks with the domains and post offices they service, or put them all 
in c: \grpwise directories on all nodes. If you put them on shared disks with domains and post 
offices, make sure there are no agent files in c: \grpwise directories on nodes to confuse the issue at a 
later time. 


Even if you choose to install the agents to the c: \grpwise directory of multiple nodes, you can still 
store the agent startup files on shared disks with the domains and post offices. The significant 
advantage of this approach is that you only have one startup file to modify per agent. 
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AGENT CLUSTERING WORKSHEET 


Under Item 1: Agent Installation Location, mark whether you will install the agent software to the 
shared disk with a domain or post office, or to each node in the cluster. If necessary, specify where the 
agent startup files will be stored. 


Under Item 2: Domain Name, transfer the domain name, shared disk, and directory from the System 
Clustering Worksheet to the Agent Clustering Worksheet. 


Under Item 5: Post Office Name, transfer the post office name, shared disk, and directory from the 
System Clustering Worksheet to the Agent Clustering Worksheet. 


Planning the Agent Services 


Ina Microsoft cluster, the MTA and POA must be set up as service resources. A service resource for a 
GroupWise agent must include the following information: 


+ Name: The name by which the agent service will be listed in the resource group (for example, 
MTA Service or POA Service) 


¢ Possible Owners: The list of nodes in the cluster to which the GroupWise agent can fail over 
(the same as the possible owners of the resource group to which the agent service belongs) 


+ Resource Dependencies: Other resources in the resource group that must be online before the 
GroupWise agent can start on a new node (for example, the Group IP Address resource and the 
Physical Disk resource where the domain or post office directory is located) 


AGENT CLUSTERING WORKSHEET 


Under Item 3: MTA Service Resource, specify the MTA service resource name and list any possible 
resource dependencies. 


Under Item 6: POA Service Resource, specify the POA service resource name and list any possible 
resource dependencies. 


Planning the Windows Agent Installation 


Aside from the cluster-specific issues discussed in the preceding sections, the considerations 
involved in planning to install the GroupWise Windows agents are the same in a Microsoft cluster as 
in any other environment. Review “Planning the GroupWise Agents”, then print and fill out the 
“GroupWise Agent Installation Summary Sheet” in “Installing GroupWise Agents” in the GroupWise 
8 Installation Guide for each location where you will install the Windows MTA and/or POA. 


Fill out the Windows Agent Worksheet. 
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GROUPWISE AGENT INSTALLATION WORKSHEET 


Under Agents and Locations, mark POA Local to Post Office and MTA Local to Domain. In a Microsoft 
cluster, a domain or post office and its agent must be located on the same node in order to fail over 
together. 


Under Installation Path, take into account your decision based on “Deciding Where to Install the Agent 
Software” on page 291. 


Under Windows Installation Options, mark Install as Windows Services. 


Under Domain Information and Post Office Information, refer to the Domain and Post Office 
Worksheets you filled out in Section 36.2, “Planning a New Clustered Domain,” on page 285 and 
Section 36.3, “Planning a New Clustered Post Office,” on page 285, and to the Network Address 
Worksheet you completed during “Planning Cluster-Unique Port Numbers for Agents in the Cluster” 
on page 289. 





IMPORTANT: Do not install the Windows agent software until you are instructed to do so in 
Chapter 37, “Setting Up a Domain and Post Office in a Microsoft Cluster,” on page 299. 


Skip to Chapter 37, “Setting Up a Domain and Post Office in a Microsoft Cluster,” on page 299. 





36.9 GroupWise Clustering Worksheets 


+ Section 36.9.1, “System Clustering Worksheet,” on page 294 
+ Section 36.9.2, “Network Address Worksheet,” on page 296 
* Section 36.9.3, “Agent Clustering Worksheet,” on page 297 


36.9.1 System Clustering Worksheet 


Item Explanation 


1) Cluster Name: Record the name of the name of your Microsoft cluster. 


For more information, see Section 36.1, “Setting Up Your 
Microsoft Cluster,” on page 284. 


2) Nodes in Cluster: List the servers that are part of the cluster that you set up for 
your GroupWise system. 


For more information, see Section 36.1, “Setting Up Your 
Microsoft Cluster,” on page 284. 
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Item 


3) Resources for GroupWise 
Administration: 


ConsoleOne: 


Shared disk: 
Possible owners: 


Software Distribution Directory: 


Shared disk: 
Possible owners: 


4) Resource Group for Domain: 


Network name: 
IP address: 
Physical disk: 
File share: 

MTA service: 
Possible owners 


Post Office in Same Resource Group as 


Domain? 


+ Yes 


+ No 


5) Resource Group for Post Office: 


Network name: 
IP address: 
Physical disk: 
File share: 

POA service: 
Possible owners: 


6) IP Address Resolution Methods: 


+ eDirectory 
¢ hosts file 


* DNS 


7) Domain Name: 


Domain Directory: 


8) Post Office Name: 


Post Office Directory: 


Explanation 


List any shared locations that you want to set up for 
ConsoleOne or the software distribution directory. 


For more information, see Section 36.6, “Planning Shared 
Administrative Resources,” on page 287. 


Specify the information for the domain resource group. 


For more information, see Section 36.2, “Planning a New 
Clustered Domain,” on page 285. 


Specify the information for the post office resource group. 


For more information, see Section 36.3, “Planning a New 
Clustered Post Office,” on page 285. 


Mark the short name address resolution methods you want to 
implement to ensure that the UNC paths stored in ConsoleOne 
with network names can be successfully resolved into physical 
network addresses. 


For more information, see Section 36.7, “Ensuring Successful 
Name Resolution for GroupWise Resource Groups,” on 
page 287 


Specify a unique name for the domain. Specify the directory 
where you want to create the new domain. 


For more information, see Section 36.2, “Planning a New 
Clustered Domain,” on page 285. 


Specify a unique name for the post office. Specify the directory 
where you want to create the post office. 


For more information, see Section 36.3, “Planning a New 
Clustered Post Office,” on page 285. 
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Item Explanation 


9) Document Storage Area Location: If you need a library for a clustered post office, mark where you 


want to create its document storage area and provide a 
+ At the post office directory if necessary. 


* Outside the post office For more information, see Section 36.4, “Planning a New 


+è Separate post office Library for a Clustered Post Office,” on page 286. 
Document Storage Area Access 


+ POA /user startup switch setting 


+ POA /password startup switch 
setting 


36.9.2 Network Address Worksheet 


+ “Domain Information” on page 296 
¢ “Post Office Information” on page 296 
+ “Internet Agent Information” on page 296 


+ “WebAccess Information” on page 297 


Domain Information 


MTA MTA MTA 


Domain IP Address MTP Port HTTP Port 


Post Office Information 


POA POA POA POA 


Post Office IP Address CIS Port MTP Port HTTP Port 


Internet Agent Information 


Internet Agent GWIA MTA ive Remote MTA GWIA 
g IP Address MTP Port Port HTTP Port HTTP Port 
GWIA Domain N/A 
MTA 
Internet Agent (same) N/A N/A N/A 
(GWIA) 
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WebAccess Information 


WebAccess 
Agent IP Address 


WebAccess 
Domain MTA 


WebAccess (same) 
Agent 
(GWINTER) 


WebAccess 
MTP Port 


Agent Clustering Worksheet 


Item 


1) Agent installation location: 


+ Shared disk with domain or post 


office 


+ Each node in the cluster 


Consolidate startup files? 


2) Domain Name: 
Domain Directory: 
3) MTA Service Resource: 


Service name: 
Possible owners: 
Resource dependencies: 


4) MTA Network Information: 


MTA IP address: 
MTA message transfer port: 
MTA HTTP port: 


5) Post Office Name: 
Post Office Directory: 
6) POA Service Resource: 


Service name: 
Possible owners: 
Resource dependencies: 


7) POA Network Information: 


POA IP address 

POA client/server port 
POA message transfer port 
POA HTTP port 


MTA WebAccess WebAccess 
HTTP Port Agent Port HTTP Port 
N/A N/A 
N/A 
Explanation 


Mark the location where you will install the agent software. 


If necessary, specify the location where you will store agent 
startup files on the same shared disk with the domain or post 
office. 


For more information, see “Deciding Where to Install the 
Agent Software” on page 291. 


Transfer this information from the System Clustering 
Worksheet (item 6). 


List other nodes in the cluster where the domain resource 
group could fail over and any resources that must be online 
before the MTA can start. 


For more information, see “Planning the Agent Services” on 
page 293. 


Gather the MTA network address information from the 
“Network Address Worksheet” on page 296. 


For more information, see “Planning Cluster-Unique Port 
Numbers for Agents in the Cluster” on page 289. 


Transfer this information from the System Clustering 
Worksheet (item 7). 


List other nodes in the cluster where post office resource 
group could fail over and any resources that must be online 
before the POA can start. 


For more information, see “Planning the Agent Services” on 
page 293. 


Gather the POA network address information from the 
“Network Address Worksheet” on page 296. 


For more information, see “Planning Cluster-Unique Port 
Numbers for Agents in the Cluster” on page 289. 
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37.1 


37.1.1 


37.1.2 


Setting Up a Domain and Post Office ina 
Microsoft Cluster 


You should have already reviewed “Planning GroupWise in a Microsoft Cluster” on page 283 and 
filled out the “System Clustering Worksheet” on page 294, the “Network Address Worksheet” on 
page 296, and the “Agent Clustering Worksheet” on page 297. You are now ready to complete the 
following tasks to set up GroupWise in your Microsoft cluster: 

¢ Section 37.1, “Preparing the Cluster for GroupWise,” on page 299 

è Section 37.2, “Setting Up a New GroupWise System in a Cluster,” on page 301 

¢ Section 37.3, “Creating a New Secondary Domain in a Cluster,” on page 301 

¢ Section 37.4, “Creating a New Post Office in a Cluster,” on page 303 

è Section 37.5, “Installing and Configuring the MTA and the POA in a Cluster,” on page 304 

¢ Section 37.6, “Testing Your Clustered GroupWise System,” on page 306 

è Section 37.7, “Managing Your Clustered GroupWise System,” on page 306 

è Section 37.8, “What’s Next,” on page 308 


Preparing the Cluster for GroupWise 


After you have set up your Microsoft cluster and become familiar with its functioning, as described 
in Chapter 35, “Introduction to GroupWise 8 and Microsoft Clusters,” on page 281, complete the 
following tasks to prepare the cluster for your GroupWise system: 


¢ Section 37.1.1, “Creating GroupWise Resource Groups,” on page 299 
¢ Section 37.1.2, “Creating Agent Service Resources,” on page 299 


¢ Section 37.1.3, “Configuring Short Name Resolution,” on page 300 


Creating GroupWise Resource Groups 


Create the needed domain and post office resource groups in your Microsoft cluster (System 
Clustering Worksheet items 3 and 4), as planned in Section 36.2, “Planning a New Clustered 
Domain,” on page 285 and Section 36.3, “Planning a New Clustered Post Office,” on page 285. 


Creating Agent Service Resources 


Within each GroupWise resource group, create the MTA or POA service resource (Agent Clustering 
Worksheet items 3 and 6), as planned in “Planning the Agent Services” on page 293. 
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Configuring Short Name Resolution 


To ensure that GroupWise resource groups are always locatable on the network, configure the short 
name resolution methods that you want to rely on for your clustered GroupWise system (System 
Clustering Worksheet item 9), as planned in Section 36.7, “Ensuring Successful Name Resolution for 
GroupWise Resource Groups,” on page 287. 

¢ “eDirectory” on page 300 

¢ “Hosts Files” on page 300 

+ “DNS” on page 300 
After configuring your selected short name resolution methods, continue with the task you need to 
perform: 

+ Section 37.2, “Setting Up a New GroupWise System in a Cluster,” on page 301 

è Section 37.3, “Creating a New Secondary Domain in a Cluster,” on page 301 


+ Section 37.4, “Creating a New Post Office in a Cluster,” on page 303 


eDirectory 


ConsoleOne uses Novell eDirectory to resolve the UNC path of a domain or post office directory into 
its network name in the cluster. For example, on the workstation where you run ConsoleOne, you 
need to map a drive to the location of a domain directory using the network name of the domain 
resource group so that ConsoleOne can access the domain database no matter which node in the 
cluster it is active on. 


Hosts Files 


Because each GroupWise resource group has been associated with a network name, you should add 
lines for the new network names to the \winnt\system32\drivers\etc\hosts file as needed This 
should only be done on the administrator’s workstation. 


The lines you add to a hosts file could look similar to the following example (all on one line, of 
course): 


Syntax: 


IP_address network_name.context 


Remember that network_name represents the name of the virtual server, which remains unchanged 
regardless of which node is currently active. 


Example: 
17216.5781 gwcluster.novell.com 


When specifying the lines in the hosts files, use System Clustering Worksheet item 7 or 8 for each 
IP_address and network_name where a domain or post office resides. Use System Clustering 
Worksheet item 3 for cluster. Use System Clustering Worksheet item 4 for context. 


DNS 


Because each GroupWise resource group has been associated with a virtual network name, you 
should add all your new network names to DNS. 
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37.3 


Setting Up a New GroupWise System in a Cluster 


The GroupWise Installation Advisor walks you through setting up the primary domain and an initial 
post office in the primary domain. You might be creating your primary domain and initial post office 
in the same resource group or in two different resource groups. After you have created the primary 
domain and initial post office and installed the GroupWise agents, you can create additional 
secondary domains and post offices in the cluster as needed. 


To set up the primary domain and initial post office for a new GroupWise system in a Microsoft 
cluster: 


1 Ifnecessary, map a drive to each GroupWise administration shared disk (System Clustering 
Worksheet item 3). 


2 Map a drive to the shared disk of the domain resource group (System Clustering Worksheet item 
6) and, if needed, to the shared disk of the post office resource group (System Clustering 
Worksheet item 7), where the primary domain and the initial post office for your new 
GroupWise system will be created. 


3 Manually create the domain directory (System Clustering Worksheet item 6) and the post office 
directory (System Clustering Worksheet item 7). 


This step is not required, but in a Microsoft cluster, the following step is easier if the directory 
already exists. 


4 Run the GroupWise Installation Advisor to set up your initial GroupWise system, following the 
steps provided in “NetWare and Windows: Setting Up a Basic GroupWise System” in “Installing 
a Basic GroupWise System” in the GroupWise 8 Installation Guide. Keep in mind the following 
cluster-specific details: 


+ When you specify the ConsoleOne directory and the software distribution directory, be sure 
to browse to each location through the shared disk accessed in Step 1 above. 


+ When you specify the domain directory and post office directory, be sure to browse through 
the shared disk accessed in Step 2 to select the directory created in Step 3 above. 


¢ For the post office link type, select TCP/IP Link. 


+ When providing the MTA and POA network address information, use the Agent Clustering 
Worksheet that you filled out in Section 36.8, “Deciding How to Install and Configure the 
Agents in a Cluster,” on page 289. The information you provide will be used to configure 
the MTA and POA objects in the domain and post office even though you have not yet 
installed the agent software. 


+ Do not create users in the post office at this time. 


+ In the Summary dialog box, the domain directory and post office directory that you 
browsed to should display as UNC paths using the network name of the GroupWise 
resource group, not the name of a specific node in the cluster. 


5 When you have finished creating the primary domain and the initial post office, continue with 
installing the GroupWise Agents, starting with Step 5 in “Installing the Agent Software in a 
Cluster” on page 304. 


The GroupWise Installation Advisor starts the Agent Installation program for you. 


Creating a New Secondary Domain in a Cluster 


After you have set up the primary domain and initial post office, as described in Section 37.2, “Setting 
Up a New GroupWise System in a Cluster,” on page 301, you can create additional secondary 
domains as needed. 
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To create a new secondary domain in a Microsoft cluster: 


1 


10 


Create a domain resource group for the new domain, as described in “Creating GroupWise 
Resource Groups” on page 299. 


Create an MTA service resource for the domain’s MTA, as described in “Creating Agent Service 
Resources” on page 299. 


Map a drive to the shared disk of the domain resource group (System Clustering Worksheet item 
7) where the new secondary domain will be created. 


Manually create the domain directory (System Clustering Worksheet item 7). 


This step is not required, but in a clustered environment, Step 7 is easier if the domain directory 
already exists. 


If you selected the same shared disk with the domain as the agent installation location (Agent 
Clustering Worksheet item 1), create the drive: \grpwise directory on the drive accessed in 
Step 3. 


or 


If you selected c:\grpwise on each node in the cluster, decide which node to install the agents 
to first. 


In ConsoleOne, connect to the primary domain in your GroupWise system, as described in 
“Connecting to a Domain” in “Domains” in the GroupWise 8 Administration Guide. 


Create the new domain, following the steps provided in “Creating the New Domain” in 
“Domains” in the GroupWise 8 Administration Guide. Keep in mind the following cluster-specific 
details: 


¢ Use the Domain Worksheet you filled out in Section 36.2, “Planning a New Clustered 
Domain,” on page 285 to fill in the fields on the Create GroupWise Domain page. 


+ In the Domain Database Location field, be sure to browse through the drive you accessed in 
Step 3 to the domain directory you created in Step 4 above. 


+ In the Link to Domain field, link the new domain to the primary domain of your GroupWise 
system. 


¢ The Configure Link option is selected by default. Select TCP/IP Link to the Other Domain. 
Refer to the Agent Clustering Worksheet that you filled out in “Planning Cluster-Unique 
Port Numbers for Agents in the Cluster” on page 289 for the resource group IP address and 
cluster-unique port numbers that you need to specify in order to configure the link. 


Use the Link Configuration tool to change the links from the new domain to all other domains in 
the cluster to direct TCP/IP links, following the steps provided in “Changing the Link Protocol 
between Domains to TCP/IP” in “Message Transfer Agent” in the GroupWise 8 Administration 
Guide. 


Although a complete mesh link configuration is the most efficient, it might not be feasible in all 
situations. Set up as many direct TCP/IP links as possible for best MTA performance in the 
cluster. 


Make sure you are still connected to the primary domain. 


Rebuild the domain database for the new domain, following the steps provided in “Rebuilding 
Domain or Post Office Databases” in “Databases” in the GroupWise 8 Administration Guide. Be 
sure to browse to the database location (System Clustering Worksheet item 7) through the 
shared disk you accessed in Step 3 to the domain directory you created in Step 4 above. 


The database rebuild is necessary in order to transfer the MTA configuration information and 
the domain link information into the secondary domain database, because the MTA for the new 
secondary domain is not yet running. 


Continue with Creating a New Post Office in a Cluster. 
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Creating a New Post Office in a Cluster 


You can create a new post office in the same resource group where its domain is located or in a 
separate resource group. If the post office and its domain are in the same resource group, they fail 
over together. If they are in separate resource groups, they fail over separately. 


To create a new post office in a Microsoft cluster: 
1 If you selected Yes for Post Office in Same Resource Group as Domain? (under System Clustering 
Worksheet item 4), map a drive to the shared disk of the domain resource group. 
or 


Map a drive to the shared disk of the post office resource group (System Clustering Worksheet 
item 5). 
2 Manually create the post office directory (System Clustering Worksheet item 8). 


This step is not required, but in a Microsoft cluster, Step 4 is easier if the post office directory 
already exists. 


3 In ConsoleOne, connect to the GroupWise domain where you want to create the new post office, 
as described in “Connecting to a Domain” in “Domains” in the GroupWise 8 Administration 
Guide. 


4 Create the new post office, following the steps provided in “Creating the New Post Office” in 
“Post Offices” in the GroupWise 8 Administration Guide. Keep in mind the following cluster- 
specific details: 


+ Use the Post Office Worksheet you filled out in Section 36.3, “Planning a New Clustered 
Post Office,” on page 285 to fill in the fields on the Create GroupWise Post Office page. 


+ In the Post Office Database Location field, be sure to browse through the shared disk you 
accessed in Step 1 to the post office directory you created in Step 2 above. 


¢ If you want to create a library at the post office (System Clustering Worksheet item 9), select 
Create Library. 


¢ The Configure Link option is selected by default. Select TCP/IP Link from Domain to New Post 
Office. Refer to the Agent Clustering Worksheet that you filled in during “Planning Cluster- 
Unique Port Numbers for Agents in the Cluster” on page 289 for the resource group IP 
address and cluster-unique port numbers that you need to specify in order to configure the 
link. 


5 In ConsoleOne, right-click the new Post Office object, then click Properties. 
6 Click GroupWise > Post Office Settings, then in the Access Mode field, select Client/Server Only. 
7 Right-click the new POA object, then click Properties. 


On the POA Agent Settings and Scheduled Events pages, you might want to specify unique 
times for the following POA activities to prevent multiple POAs from performing the same 
activities on the same node at the same time during a failover situation: 


¢ Start User Upkeep 

+ Generate Address Book for Remote 
¢ Enable QuickFinder Indexing 

¢ Mailbox/Library Maintenance Event 


For more information about these repetitive POA activities, see “Performing Nightly User 
Upkeep”, “Regulating Indexing”, and “Scheduling Database Maintenance” in “Post Office 
Agent” in the GroupWise 8 Administration Guide. 


8 Make sure you are still connected to the domain that owns the new post office. 
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9 Rebuild the post office database for the new post office, following the steps provided in 
“Rebuilding Domain or Post Office Databases” in “Databases” in the GroupWise 8 Administration 
Guide. Be sure to browse to the database location (System Clustering Worksheet item 7) through 
the shared disk you accessed in Step 1 to the post office directory you created in Step 2 above. 


The database rebuild is necessary in order to transfer the POA configuration information and 
the post office link information into the post office database, because the POA for the new post 
office is not yet running. 


10 If you want to create a library (System Clustering Worksheet item 9) for the new clustered post 
office, follow the steps in “Setting Up a Basic Library” or “Setting Up a Full-Service Library” in 
“Libraries and Documents” in the GroupWise 8 Administration Guide, after you have completely 
finished setting up the new clustered post office. 


11 Continue with Installing and Configuring the MTA and the POA in a Cluster. 


Installing and Configuring the MTA and the POA in a 
Cluster 


After you have created a new domain and/or post office, you are ready to install and configure the 
GroupWise agents. Complete all the tasks below if you are setting up a new GroupWise system or if 
you have created a new GroupWise resource group where you want to install the agent software: 
* Section 37.5.1, “Installing the Agent Software in a Cluster,” on page 304 
¢ Section 37.5.2, “Editing Clustered Agent Startup Files,” on page 305 
+ Section 37.5.3, “Setting Up New Instances of the Agents without Installing the Agent Software,” 
on page 306 


Under some circumstances, the agent software has already been installed in the cluster and you 
simply need to create a new startup file specific to the new domain or post office. For example: 


¢ You have created anew domain and/or post office in a GroupWise resource group where the 
agent software is already installed in the drive: \grpwise directory for the resource group. 
+ In your GroupWise system, the agent software is already installed to the c: \grpwise directory 


on each node in the cluster. 


In these circumstances, follow the instructions in “Setting Up New Instances of the Agents without 
Installing the Agent Software” on page 306 instead of completing the tasks listed above. 


Installing the Agent Software in a Cluster 


To install the MTA and the POA: 
1 Map a drive to the shared disk of the domain resource group (Agent Clustering Worksheet item 
2) or the post office resource group (Agent Clustering Worksheet item 5). 


2 Map a drive to c: \ on the first node in the cluster where you will set up the agents as Windows 
services (System Clustering Worksheet item 2). 


3 If you plan to install the agent software to the shared disk of the domain or post office resource 
group (under Agent Clustering Worksheet item 1), create the drive: \grpwise directory on the 
shared disk accessed in Step 1. 


or 


If you plan to install the agent software to each node in the cluster, create the c: \grpwise 
directory on the drive accessed in Step 2. 
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4 Start the Agent Installation program, following the steps provided in “Installing the Windows 
Agent Software” in “Installing GroupWise Agents” in the GroupWise 8 Installation Guide. 


5 Install the Windows agents, keeping in mind the following cluster-specific details: 


+ Use the Windows Agent Clustering Worksheet that you filled out in “Planning the 
Windows Agent Installation” on page 293 to fill in the fields during the agent installation 
process. 


¢ On the Installation Path page, be sure to browse through the mapped drive to the directory 
you created in Step 3 above. Be sure that Install as Windows Services is selected. 


+ On the Domains / Post Offices page, click Add for each domain and post office that the 
agents will service. In the Path to Database field, be sure to browse through the drive you 
mapped in Step 1 above to the domain directory or the post office directory on the shared 
disk. 


+ On the Installation Complete page, do not select Launch GroupWise Agents Now. 


6 If you need to install the agent software to c: \grpwise on each node in the cluster, repeat Step 4 
and Step 5, mapping a drive to each node in the cluster. 


or 


If you installed the agent software to a shared disk and need only to set up the agents as 
Windows services on each node, repeat Step 4 and Step 5, mapping drives to new nodes as 
needed. On the Installation Options page, select only the Install as Windows Services option to 
speed up the installation process for each node. 


7 If you installed the agent software to each node and you selected Yes for Consolidate Startup Files? 
(under Agent Clustering Worksheet item 1), copy one complete set of agent startup files to the 
planned location on the shared disk, then delete all agent startup files from the c: \grpwise 
directories on the nodes to avoid future confusion. 


8 Continue with Editing Clustered Agent Startup Files. 


Editing Clustered Agent Startup Files 


By default, the Agent Installation program creates agent startup files in the agent installation 
directory. Each MTA startup file is named after the domain it services, with a .mta extension. Each 
POA startup file is named after the post office it services, with a .poa extension. 


Because you mapped a drive to the shared disk of the GroupWise resource group using the physical 
disk and file share information from the resource group, the setting for the MTA /home startup 
switch and the POA /home startup switch are always correct, no matter which node in the cluster the 
domain and post office are currently active on. 


One manual modification of POA startup files is required for robust functionality in a Microsoft 
cluster. Uncomment the /ip startup switch and provide the IP address of the post office resource 
group (Agent Clustering Worksheet item 7). This information is available to the POA in its eDirectory 
object properties. However, in some failover situations, the POA reconnects to the MTA more quickly 
when the information is immediately available to the POA in its startup file. 


If the POA needs to access a remote document storage area that is outside the cluster, add the /user 
and /password startup switches (under System Clustering Worksheet item 9) in order to provide a 
user name and password that the POA can use to access the server where the document storage area 
resides. As an alternative to startup switches, you can assign the POA object all rights except 
Supervisor and Access control, as long as the remote document storage area is located in the same 
tree with the post office. 


Skip to Section 37.6, “Testing Your Clustered GroupWise System,” on page 306. 
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37.6 


37.7 


37.7.1 


Setting Up New Instances of the Agents without Installing the Agent 
Software 


To set up new instances of the agents without installing the agent software, you simply create new 
startup files. Each MTA startup file is named after the domain it services, with a .mta extension. Each 
POA startup file is named after the post office it services, with a . poa extension. 


If the existing agent software is located in the drive:\grpwise directory of a shared disk with a 
domain or post office, the startup files are located there as well. If the existing agent software is 
located in the c: \grpwise directory on each node in the cluster, the startup files might be located 
there, or they might be located on the shared disk with the domain or post office. 


To create a new startup file without installing the agent software: 
1 Make a copy of an existing startup file and name it after the domain or post office that will be 
serviced by the new instance of the agent. 


2 Edit the setting of the /home startup switch to point to the location of the new domain directory 
or post office directory. Be careful to maintain the syntax of the original line, using the physical 
disk and file share provided in the GroupWise resource group. 


3 Scroll down through the startup file looking for other active (not commented out) startup 
switches, then modify them as needed for the new instance of the agent. 


4 Save the new startup file. 


5 Continue with Testing Your Clustered GroupWise System. 


Testing Your Clustered GroupWise System 


After you have configured the GroupWise resource group, you can test the failover and failback 
functionality by bringing the GroupWise resource group online and taking it offline again. 


Continue with Managing Your Clustered GroupWise System. 


Managing Your Clustered GroupWise System 


After you have set up a basic clustered GroupWise system, you should consider some long-term 
management issues. 
+ Section 37.7.1, “Updating GroupWise Objects with Cluster-Specific Descriptions,” on page 306 
* Section 37.7.2, “Knowing What to Expect in MTA and POA Failover Situations,” on page 308 


Updating GroupWise Objects with Cluster-Specific Descriptions 


After setting up your clustered GroupWise system, while the cluster-specific information is fresh in 
your mind, you should record that cluster-specific information as part of the GroupWise objects in 
ConsoleOne so that you can easily refer to it later. Be sure to keep the information recorded in the 
GroupWise objects up to date if the configuration of your system changes. 

+ “Recording Cluster-Specific Information for a Domain and Its MTA” on page 307 

¢ “Recording Cluster-Specific Information for a Post Office and Its POA” on page 307 


¢ “Recording Cluster-Specific Information for a Software Distribution Directory” on page 307 
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Recording Cluster-Specific Information for a Domain and Its MTA 


To permanently record important cluster-specific information for the domain: 


1 In ConsoleOne, browse to and right-click the Domain object, then click Properties. 


2 Inthe Description field of the domain Identification page, provide a cluster-specific description of 
the domain, including the resource group IP address and the cluster-unique port numbers used 
by its MTA. 


Click OK to save the domain description. 
Select the Domain object to display its contents. 
Right-click the MTA object, then click Properties. 
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In the Description field of the MTA Identification page, record the domain resource group IP 
address and the cluster-unique port numbers used by the MTA. 


This information appears on the MTA console, no matter which node in the cluster it is currently 
running on. 


7 Click OK to save the MTA description. 
8 Continue with Recording Cluster-Specific Information for a Post Office and Its POA. 


Recording Cluster-Specific Information for a Post Office and Its POA 
To permanently record important cluster-specific information for a post office: 


1 In ConsoleOne, browse to and right-click the Post Office object, then click Properties. 


2 Inthe Description field of the post office Identification page, provide a cluster-specific 
description of the post office, including the resource group IP address and the cluster-unique 
port numbers used by its POA. 


Click OK to save the post office description. 
Select the Post Office object to display its contents. 
Right-click the POA object, then click Properties. 
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In the Description field of the POA Identification page, record the post office resource group IP 
address and the cluster-unique port numbers used by the POA. 


This information appears on the POA console, no matter which node in the cluster it is currently 
running on. 


7 Click OK to save the POA description. 


8 If necessary, continue with “Recording Cluster-Specific Information for a Software Distribution 
Directory” on page 307. 


or 


Skip to “Knowing What to Expect in MTA and POA Failover Situations” on page 308. 


Recording Cluster-Specific Information for a Software Distribution Directory 


To permanently record important cluster-specific information about a software distribution directory 
located on a shared disk: 


1 In ConsoleOne, click Tools > System Operations > Software Directory Management. 


2 Select the software distribution directory, then click Edit. 
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37.8 


3 Inthe Description field, record the IP address of the cluster resource where the software 
distribution directory resides. 


4 Click OK, then click Close to save the software distribution directory description. 
5 Continue with Knowing What to Expect in MTA and POA Failover Situations. 


Knowing What to Expect in MTA and POA Failover Situations 


In a failover situation, the agents might need to perform some database repair as they start on the 
new node. The time required depends on the size of the databases involved. 


Typically, the POA returns to full functionality faster than the MTA. This benefits GroupWise client 
users, who can reconnect to their mailboxes very quickly and probably do not notice if messages to 
users in other post offices are not delivered immediately. The only time a user would need to restart 
the GroupWise client would be if he or she was actually in the process of sending a message when the 
POA went down. Notify can continue running even if the connection to the POA becomes 
unavailable and then it reconnects automatically when the POA is again available. 


The MTA typically takes some time reestablishing the links to its post offices, other domains, and 
gateways, but this situation usually resolves itself in a few minutes without administrator 
intervention. If it does not, you can manually restart the MTA to speed up the process. 


In comparison to failover, manual migration typically takes longer because the agents methodically 
terminate their threads and close their databases as part of their normal shutdown procedure. 
However, as a result, no database repair is required when the agents start up again in their new 
location. 


Continue with What’s Next. 


What’s Next 


Now that you have at least one GroupWise domain and post office up and running in your Microsoft 
cluster, you are ready to proceed with the rest of your GroupWise system setup by: 


¢ Adding users to post offices. See “Users” in the GroupWise 8 Administration Guide. 


+ Setting up the GroupWise client software and helping users to get started using it. See “Client” 
in the GroupWise 8 Administration Guide. Also see the GroupWise 8 Windows Client User Guide. 


+ Connecting your clustered GroupWise system to the Internet. See Chapter 38, “Implementing 
the Internet Agent in a Microsoft Cluster,” on page 309. 


¢ Providing access to users’ GroupWise mailboxes from their Web browsers. See Chapter 39, 
“Implementing WebAccess in a Microsoft Cluster,” on page 319. 


+ Connecting your clustered GroupWise system to other e-mail systems through GroupWise 
gateways. See Chapter 40, “Implementing GroupWise Gateways in a Microsoft Cluster,” on 
page 331. 


+ Monitoring the status of your clustered GroupWise system from your Web browser. See 
Chapter 41, “Monitoring a GroupWise System in a Microsoft Cluster,” on page 333. 


¢ Backing up your clustered GroupWise system. See Chapter 42, “Backing Up a GroupWise 
System in a Microsoft Cluster,” on page 335. 
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38.1 


Implementing the Internet Agent ina 
Microsoft Cluster 


You should already have set up at least a basic GroupWise system, as described in Chapter 36, 
“Planning GroupWise in a Microsoft Cluster,” on page 283 and Chapter 37, “Setting Up a Domain 
and Post Office in a Microsoft Cluster,” on page 299. As part of this process, the “System Clustering 
Worksheet” on page 294 and the “Network Address Worksheet” on page 296 were filled out. If you 
do not have access to the filled-out worksheets, print the worksheets now and fill in the clustering 
and network address information as it currently exists on your system. You need this information as 
you implement the Internet Agent in a cluster. 

¢ Section 38.1, “Planning the Internet Agent in a Cluster,” on page 309 

è Section 38.2, “Setting Up the Internet Agent in a Cluster,” on page 312 

+ Section 38.3, “Managing the Internet Agent in a Cluster,” on page 316 


+ Section 38.4, “Internet Agent Clustering Worksheet,” on page 317 


Planning the Internet Agent in a Cluster 


A main system configuration difference between a GroupWise system in a clustering environment 
and a GroupWise system in a regular environment is that you need to create a separate domain to 
house each GroupWise gateway, including the Internet Agent. The Internet Agent is faster and more 
stable when it runs on the same server with its domain. In a cluster, creating a separate domain for 
the Internet Agent ensures that the Internet Agent and its domain always fail over together. 


Section 38.4, “Internet Agent Clustering Worksheet,” on page 317 lists all the information you need as 
you set up the Internet Agent in a Microsoft cluster. You should print the worksheet and fill it out as 
you complete the tasks listed below: 

¢ Section 38.1.1, “Planning a Domain for the Internet Agent,” on page 310 

+ Section 38.1.2, “Planning the Internet Agent Resource Group,” on page 310 


+ Section 38.1.3, “Planning Cluster-Unique Port Numbers for the Internet Agent and Its MTA,” on 
page 310 


+ Section 38.1.4, “Preparing Your Firewall for the Internet Agent,” on page 311 

+ Section 38.1.5, “Deciding Where to Install the Internet Agent and Its MTA,” on page 311 
è Section 38.1.6, “Planning the MTA Installation,” on page 312 

¢ Section 38.1.7, “Planning the Internet Agent Installation,” on page 312 
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38.1.1 


38.1.2 


38.1.3 


Planning a Domain for the Internet Agent 


The considerations involved in planning a domain for the Internet Agent are much the same as 
planning any other domain. In preparation, review “Planning a New Domain”, then print and fill out 
the “Domain Worksheet” in “Domains” in the GroupWise 8 Administration Guide. 


Keep in mind the following cluster-specific details: 


+ When you specify the location for the domain directory on the Domain Worksheet, include the 
shared disk where you want the domain directory to be located. 


+ Do not concern yourself with the GroupWise agent information on the Domain Worksheet. You 
can stop with item 10. You will plan the MTA installation later. 


When you have completed the Domain Worksheet, transfer the key information from the Domain 
Worksheet to the Internet Agent Clustering Worksheet. 


INTERNET AGENT CLUSTERING WORKSHEET 


Under Item 1: Resource Group for Internet Agent, transfer the disk drive to the Internet Agent 
Clustering Worksheet. 


Under Item 2: Internet Agent Domain Name, transfer the domain name and directory to the Internet 
Agent Clustering Worksheet. 


Planning the Internet Agent Resource Group 


The Internet Agent resource group is similar to the GroupWise resource groups you have already set 
up, as described in Section 36.5, “Planning GroupWise Resource Groups,” on page 286 and “Creating 
GroupWise Resource Groups” on page 299. The Internet Agent resource group contains a domain 
whose only role is to connect the Internet Agent into your clustered GroupWise system. It also 
contains two agent service resources, one for the MTA that services the domain and one for the 
Internet Agent. 


INTERNET AGENT CLUSTERING WORKSHEET 


Under Item 1: Resource Group for Internet Agent, specify the network name and other required 
information for the Internet Agent resource group. 


To ensure successful short name resolution, add entries for the Internet Agent network name to 
support your preferred methods of short name resolution, as described in “Configuring Short Name 
Resolution” on page 300. 


Planning Cluster-Unique Port Numbers for the Internet Agent and Its 
MTA 


As with the MTA and the POA, the Internet Agent needs cluster-unique port numbers. As part of 
planning to install the MTA and POA, you should already have determined the resource group IP 
address and cluster-unique port numbers for the Internet Agent and its MTA as you filled out the 
“Network Address Worksheet” on page 296. If you do not have a filled-out copy of this worksheet for 
your system, print it now and fill in current system information. 
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38.1.5 


INTERNET AGENT CLUSTERING WORKSHEET 


Under Item 5: MTA Network Information, transfer the resource group IP address and cluster-unique 
port numbers from the Internet Agent section of the Network Address Worksheet to the Internet Agent 
Clustering Worksheet. 


Under Item 7: Internet Agent Network Information, transfer the resource group IP address (the same 
as for its MTA) and the cluster-unique Internet Agent port number from the Internet Agent section of 
the Network Address Worksheet to the Internet Agent Clustering Worksheet. 


Preparing Your Firewall for the Internet Agent 


The Internet Agent receives incoming messages on the IP address of the Internet Agent resource 
group. Your firewall configuration must be modified to allow inbound TCP/IP traffic from the 
Internet to the Internet Agent IP address on the following standard ports: 


Table 38-1 Standard Ports 


Protocol Standard Port 
IMAP4 143 

LDAP 389 

POP3 110 

SMTP 25 


By default, the Internet Agent sends outgoing messages on the IP address of the node where it is 
running. If you decide to use this default configuration, your firewall must be configured to allow 
outbound TCP/IP traffic from all nodes on the Internet Agent resource group’s possible owners list. 


If the Internet Agent has a large number of nodes in its possible owners list, you could configure the 
Internet Agent to send outgoing messages to a relay host, which would then send them out through 
the firewall using its own IP address rather than the IP address of the particular node where the 
Internet Agent is running. This reduces the amount of modification to your firewall required to set 
up the Internet Agent. However, if the relay host goes down, all outgoing messages are delayed. 


As another alternative, you can configure the Internet Agent to use its resource group IP address for 
sending as well as receiving messages. Setup instructions for this configuration are provided in 
“Forcing Use of the Internet Agent Secondary IP Address” on page 75, which you can complete after 
installing the Internet Agent. 


In preparation for installing the Internet Agent, configure your firewall as needed to handle the 
Internet Agent’s use of node and resource group IP addresses when sending and receiving messages. 


Deciding Where to Install the Internet Agent and Its MTA 


The default Internet Agent installation directory is c: \grpwise\gwia. As with the MTA and the 
POA, you can choose to install the Internet Agent and its MTA to each node in the cluster or to the 
shared disk of the Internet Agent resource group. For a discussion of these alternatives, see 
“Deciding Where to Install the Agent Software” on page 291, which describes the issues in the 
context of planning MTA and POA installations. As with the MTA and POA, the Internet Agent and 
its MTA must be installed as Windows services. 
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INTERNET AGENT CLUSTERING WORKSHEET 


Under Item 4: MTA Installation Location and Item 6: Internet Agent Installation Location, mark whether 
you will install the Internet Agent and its MTA to the shared disk of the Internet Agent resource group 
or to each node in the cluster. If necessary, specify where the MTA startup file and the Internet Agent 
configuration file (gwia . cfg) will be stored. 


38.1.6 Planning the MTA Installation 


Follow the instructions in “Planning the Windows Agent Installation” on page 293 to plan the MTA 
installation for the Internet Agent domain, then return to this point. After you follow the instructions, 
you will have a filled-out Windows Agent Worksheet to use when you install the MTA. 





IMPORTANT: Do not install the Windows MTA until you are instructed to do so in Section 38.2, 
“Setting Up the Internet Agent in a Cluster,” on page 312. 





38.1.7 Planning the Internet Agent Installation 


Aside from the cluster-specific issues discussed in the preceding sections, the considerations 
involved in planning to install the Internet Agent are the same in a Microsoft cluster as for any other 
environment. Review “NetWare and Windows: Installing the Internet Agent Software”, then print 
and fill out the “GroupWise Internet Agent Installation Summary Sheet” in “Installing the 
GroupWise Internet Agent” in the GroupWise 8 Installation Guide. You need this information as you 
install the Internet Agent in your cluster. 





IMPORTANT: Do not install the Internet Agent software until you are instructed to do so in 
Section 38.2, “Setting Up the Internet Agent in a Cluster,” on page 312. 





38.2 Setting Up the Internet Agent in a Cluster 


You should already have reviewed Section 38.1, “Planning the Internet Agent in a Cluster,” on 
page 309 and filled out Section 38.4, “Internet Agent Clustering Worksheet,” on page 317. You are 
now ready to complete the following tasks to set up the Internet Agent in a Microsoft cluster: 

+ Section 38.2.1, “Setting Up the Internet Agent Resource Group,” on page 312 

+ Section 38.2.2, “Creating a Domain for the Internet Agent,” on page 313 

è Section 38.2.3, “Installing the MTA for the Internet Agent Domain,” on page 313 

¢ Section 38.2.4, “Installing and Configuring the Internet Agent in a Cluster,” on page 313 

+ Section 38.2.5, “Testing the Clustered Internet Agent,” on page 316 


38.2.1 Setting Up the Internet Agent Resource Group 


1 Create the Internet Agent resource group and agent services resources (Internet Agent 
Clustering Worksheet item 1), as planned in “Planning the Internet Agent Resource Group” on 
page 310. 


2 To ensure successful short name resolution, add entries for the Internet Agent network name to 
support your preferred methods of short name resolution, as described in “Configuring Short 
Name Resolution” on page 300. 
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38.2.2 


38.2.3 


38.2.4 


3 To ensure that the Internet Agent has incoming and outgoing access to the Internet, make sure 
your firewall is properly configured, as described in “Preparing Your Firewall for the Internet 
Agent” on page 311. 


4 Continue with Creating a Domain for the Internet Agent. 


Creating a Domain for the Internet Agent 


The Internet Agent domain will be a secondary domain. To create it, follow the instructions in 
Section 37.3, “Creating a New Secondary Domain in a Cluster,” on page 301, taking your information 
from the Internet Agent Clustering Worksheet, rather than the System Clustering Worksheet, then 
return to this point. 


Do not create any post offices in the Internet Agent domain. 


Continue with Installing the MTA for the Internet Agent Domain. 


Installing the MTA for the Internet Agent Domain 


The MTA for the Internet Agent domain can be installed just like any other MTA in your clustered 
GroupWise system. Follow the instructions in “Installing the Agent Software in a Cluster” on 
page 304, then return to this point. 


You do not need to edit the MTA startup file. 


Continue with Installing and Configuring the Internet Agent in a Cluster. 


Installing and Configuring the Internet Agent in a Cluster 


After you have created a domain for the Internet Agent and installed the MTA for that domain, you 
are ready to install and configure the Internet Agent. 

¢ “Installing the Internet Agent Software in a Cluster” on page 313 

+ “Enabling Internet Addressing for Your Clustered GroupWise System” on page 314 

¢ “Verifying Internet Agent Object Properties” on page 314 


Installing the Internet Agent Software in a Cluster 


1 Map a drive to the shared disk of the Internet Agent resource group (Internet Agent Clustering 
Worksheet item 1). 


2 Map a drive to c: \ on the first node in the cluster where you will set up the Internet Agent as a 
Windows service (System Clustering Worksheet item 2). 


3 If you plan to install the Internet Agent software to the shared disk of the Internet Agent 
resource group (Internet Agent Clustering Worksheet item 6), create the drive: \grpwise\gwia 
directory on the shared disk accessed in Step 1. 


or 


If you plan to install the Internet Agent software to each node in the cluster, create the 
c:\grpwise\gwia directory on the drive accessed in Step 2). 


4 Start the Internet Agent Installation program, following the steps provided in “NetWare and 
Windows: Installing the Internet Agent Software” in “Installing the GroupWise Internet Agent” 
in the GroupWise 8 Installation Guide. 
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5 Install the Windows Internet Agent, keeping in mind the following cluster-specific details: 


¢ Use the Windows Internet Agent Clustering Worksheet that you filled out in “Planning the 
Internet Agent Installation” on page 67 to fill in the fields during the Internet Agent 
installation process. 


+ On the Installation Path page, be sure to browse through the mapped drive to the directory 
you created in Step 3 above. Be sure that Run WebAccess Agent as a Windows Service is 
selected. 


+ On the GroupWise Domain page, be sure to browse through the drive you mapped in 
Step 1 to the domain directory on the shared disk. 


+ On the Post Installation Task List page, deselect Launch Internet Agent Now so that the 
Installation program does not start the Internet Agent after installation is complete. 


6 Repeat Step 4 and Step 5, mapping a drive to each node in the cluster. 


Even if you installed the Internet Agent software to a shared disk, you need to repeat the 
installation process for each node so that the Internet Agent gets set up as a Windows service on 
each node. 


7 If you installed the software to each node in the cluster and you selected Yes for Consolidate 
Configuration Files? (under Internet Agent Clustering Worksheet item 6), copy the gwia. cfg file 
to the planned location on the shared disk, then delete it from the c: \grpwise\gwia directory 
on each node to avoid future confusion. 


8 Make sure you have completed all the tasks described in “Installing the GroupWise Internet 
Agent” in the GroupWise 8 Installation Guide. 


9 Continue with Enabling Internet Addressing for Your Clustered GroupWise System. 


Enabling Internet Addressing for Your Clustered GroupWise System 


Setting up Internet addressing for a clustered Internet Agent is no different from setting it up for an 
Internet Agent in a any other environment. Follow the instructions in “Enabling Internet 
Addressing” in “System” in the GroupWise 8 Administration Guide, then continue with Verifying 
Internet Agent Object Properties. 


Verifying Internet Agent Object Properties 


During installation of the Internet Agent, the Internet Agent object should have been configured 
correctly. However, it can be helpful to verify certain cluster-specific information in order to 
familiarize yourself with the configuration of a clustered Internet Agent. 

+ “Accessing Internet Agent Object Properties” on page 314 

¢ “Verifying the Reference to the Network Name for Use by DNS” on page 315 

¢ “Verifying the Reference to the Network Name in Directory Paths” on page 315 

¢ “Verifying Post Office Links” on page 315 

¢ “Forcing Use of the Internet Agent Resource Group IP Address” on page 315 


Accessing Internet Agent Object Properties 


1 In ConsoleOne, browse to and select the Internet Agent domain in order to display its contents. 
2 Right-click the Internet Agent object, then click Properties. 


3 Continue with Verifying the Reference to the Volume Resource. 
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Verifying the Reference to the Network Name for Use by DNS 
In the Internet Agent object properties page tabs: 


1 Click SMTP/MIME > Settings. 
2 Verify the contents of the Hostname/DNS “A Record” Name field. 


It displays the hostname as currently configured in DNS. It should match the network name of 
the domain resource group, not the name of a node in the cluster. 


3 Make changes if necessary. 


4 Continue with Verifying the Reference to the Network Name in Directory Paths. 


Verifying the Reference to the Network Name in Directory Paths 
In the Internet Agent object properties page tabs: 


1 Click Server Directories. 


2 Verify that the displayed directories match the network name of the domain resource group, not 
the name of a node in the cluster. 


3 Make changes if necessary. 
4 Continue with Verifying Post Office Links. 


Verifying Post Office Links 
In the Internet Agent object properties page tabs: 


1 Click Post Office Links. 


2 Verify that the Access Mode column displays C/S (for client/server mode) for all post offices 
serviced by the clustered Internet Agent. 


3 Verify that the Links column displays the IP addresses of the post office resource groups, not the 
IP addresses of any nodes in the cluster. 


4 Make changes if necessary. 


5 Continue with Forcing Use of the Internet Agent Resource Group IP Address. 


Forcing Use of the Internet Agent Resource Group IP Address 


If you want the Internet Agent to send outgoing messages on its resource group IP address, rather 
than using the default the node IP address: 


1 Click GroupWise > Network Address. 


2 Inthe TCP/IP Address field, provide the resource group IP address (Internet Agent Clustering 
Worksheet item 1) for the Internet Agent to use for sending outgoing messages. 


3 Click SMTP/MIME, then click Settings. 

4 Select Bind to TCP/IP Address at Connection Time. 

5 Click OK. 

6 Continue with Testing the Clustered Internet Agent. 
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38.2.5 


38.3 


38.3.1 


Testing the Clustered Internet Agent 


After you have set up the Internet Agent resource group, you can test it by manually bringing it 
online and taking it offline again. 


Continue with Managing the Internet Agent in a Cluster. 


Managing the Internet Agent in a Cluster 


After you have installed the Internet Agent in a cluster, you should consider some long-term 
management issues. 
¢ Section 38.3.1, “Updating GroupWise Objects with Cluster-Specific Descriptions,” on page 316 
+ Section 38.3.2, “Knowing What to Expect in an Internet Agent Failover Situation,” on page 317 


Updating GroupWise Objects with Cluster-Specific Descriptions 


After installing the Internet Agent in your clustered GroupWise system, while the cluster-specific 
information is fresh in your mind, you should record that cluster-specific information as part of the 
GroupWise objects in ConsoleOne so that you can easily refer to it later. Be sure to update the 
information recorded in the GroupWise objects if the configuration of your system changes. 


+ “Recording Cluster-Specific Information about the Internet Agent Domain and Its MTA” on 
page 316 


¢ “Recording Cluster-Specific Information about the Internet Agent” on page 317 


Recording Cluster-Specific Information about the Internet Agent Domain and Its 
MTA 


To permanently record important cluster-specific information for the Internet Agent domain: 


1 In ConsoleOne, browse to and right-click the Domain object, then click Properties. 


2 Inthe Description field of the Internet Agent domain Identification page, provide a cluster- 
specific description of the Internet Agent domain, including its resource group IP address and 
the cluster-unique port numbers used by its MTA. 


Click OK to save the Internet Agent domain description. 
Select the Internet Agent Domain object to display its contents. 
Right-click the MTA object, then click Properties. 
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In the Description field of the MTA Identification page, record the domain resource group IP 
address and the cluster-unique port numbers used by the MTA. 


This information appears on the MTA console, no matter which node in the cluster it is currently 
running on. 


7 Click OK to save the MTA description. 


8 Continue with Recording Cluster-Specific Information about the Internet Agent. 
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38.4 


Recording Cluster-Specific Information about the Internet Agent 


With the contents of the Internet Agent domain still displayed: 


1 Right-click the Internet Agent object, then click Properties. 
2 Click GroupWise, then click Identification. 


3 Inthe Description field, record the resource group IP address and the cluster-unique port 
numbers used by the Internet Agent. 


This information appears on the Internet Agent console, no matter which node in the cluster it is 
currently running on. 


4 Click OK to save the Internet Agent information. 


5 Continue with Knowing What to Expect in an Internet Agent Failover Situation. 


Knowing What to Expect in an Internet Agent Failover Situation 


The failover behavior of the MTA for the Internet Agent domain is the same as for an MTA ina 
regular domain. See “Knowing What to Expect in MTA and POA Failover Situations” on page 308. 


Failover of the Internet Agent itself is more complex. The various e-mail clients (POP3, IMAP4, and 
LDAP) receive an error message when the server they were connected to becomes unavailable. Most 
of the clients do not attempt to reconnect automatically, so the user must exit the e-mail client and 
restart it to reestablish the connection after the failover process is complete. Fortunately, the Internet 
Agent restarts quickly in its failover location so users can reconnect quickly. 


As with the MTA and the POA, manual migration of the Internet Agent takes longer than failover. In 
fact, the Internet Agent can seem especially slow to shut down properly, as it finishes its normal 
processing and stops its threads. For a busy Internet Agent, you might need to wait several minutes 
for it to shut down properly when you are manually migrating it. 


Internet Agent Clustering Worksheet 


Item Explanation 


1) Resource Group for Internet Specify the information for the Internet Agent resource group. 


Agent: 
For more information, see “Planning the Internet Agent Resource 


Network name: Group” on page 310. 
IP address: 

Physical disk: 

File share: 

MTA service resource: 

Internet Agent service resource: 

Possible owners: 


2) Internet Agent Domain Name: Specify a unique name for the Internet Agent domain. Specify the 
a directory on the physical disk that belongs to the Internet Agent 
Domain Directory: resource group where you want to create the new domain. 


For more information, see “Planning a Domain for the Internet Agent” 
on page 310. 
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Item 
4) MTA Installation Location: 


+ Shared disk of the Internet 
Agent resource group 
+ Each node in the cluster 
Consolidate MTA startup 
files? 
5) MTA Network Information: 
MTA IP address: 
MTA message transfer port: 


MTA live remote port: 
MTA HTTP port 


6) Internet Agent Installation 
Location: 


+ Shared disk in the Internet 
Agent resource group 

+ Each node in the cluster 
Consolidate configuration 


files? 


7) Internet Agent Network 
Information: 


Internet Agent IP address: 
Internet Agent HTTP port: 
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Explanation 


Mark the location where you will install the MTA software. If 
necessary, specify the location where you will consolidate the MTA 
startup files from the various nodes where the Internet Agent is 
installed. 


For more information, see “Deciding Where to Install the Internet 
Agent and Its MTA” on page 311. 


Gather the MTA network address information from the Internet Agent 
section of the “Network Address Worksheet” on page 296. 


For more information, see “Planning Cluster-Unique Port Numbers for 
the Internet Agent and Its MTA” on page 310. 


Mark the location where you will install the Internet Agent software. 


If necessary, specify the location on the shared disk of the Internet 
Agent resource group where you will consolidate the Internet Agent 
configuration files (gwia . cfg) from the various nodes where it is 
installed. 


For more information, see “Deciding Where to Install the Internet 
Agent and Its MTA” on page 311. 


Gather the Internet Agent network address information from the 
Internet Agent section of the “Network Address Worksheet” on 
page 296. 


For more information, see “Planning Cluster-Unique Port Numbers for 
the Internet Agent and Its MTA” on page 310. 


39.1 


39.2 


Implementing WebAccess in a Microsoft 
Cluster 


You should already have set up at least a basic GroupWise system, as described in Chapter 36, 
“Planning GroupWise in a Microsoft Cluster,” on page 283 and Chapter 37, “Setting Up a Domain 
and Post Office in a Microsoft Cluster,” on page 299. As part of this process, the “System Clustering 
Worksheet” on page 294 and the “Network Address Worksheet” on page 296 were filled out. If you 
do not have access to the filled-out worksheets, print the worksheets now and fill in the clustering 
and network address information as it currently exists on your system. You will need this 
information as you implement WebAccess in a cluster. 

+ Section 39.1, “Understanding the WebAccess Components,” on page 319 

è Section 39.2, “Planning WebAccess in a Cluster,” on page 319 

+ Section 39.3, “Setting Up WebAccess in a Cluster,” on page 323 

+ Section 39.4, “Managing WebAccess in a Cluster,” on page 326 


+ Section 39.5, “WebAccess Clustering Worksheet,” on page 328 


Understanding the WebAccess Components 


If you are not familiar with GroupWise WebAccess, review “GroupWise WebAccess Overview” in 
“Installing GroupWise WebAccess” in the GroupWise 8 Installation Guide. 


As you plan WebAccess in a clustering environment, you must keep in mind that you will plan and 
set up two separate WebAccess components: 
e WebAccess Agent (gwinter.exe) that will be associated with a GroupWise WebAccess domain 


¢ WebAccess Application (a Java servlet) that will be added to your Web server 


Planning WebAccess in a Cluster 


A main system configuration difference between a GroupWise system in a clustering environment 
and a GroupWise system in a regular environment is that you need to create a separate domain to 
house each GroupWise gateway, including the WebAccess Agent. The WebAccess Agent is faster and 
more stable when it runs on the same server with its domain. In a cluster, creating a separate domain 
for the WebAccess Agent ensures that the WebAccess Agent and its domain always fail over together. 


Section 39.5, “WebAccess Clustering Worksheet,” on page 328 lists all the information you need as 
you set up the WebAccess Agent and the WebAccess Application in a clustering environment. You 
should print the worksheet and fill it out as you complete the tasks listed below: 

+ Section 39.2.1, “Setting Up Your Web Server in the Microsoft Cluster,” on page 320 

è Section 39.2.2, “Planning a New Domain for the WebAccess Agent,” on page 320 

+ Section 39.2.3, “Planning the WebAccess Resource Group,” on page 321 
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39.2.2 


+ Section 39.2.4, “Planning Cluster-Unique Port Numbers for the WebAccess Agent and Its MTA,” 
on page 321 


+ Section 39.2.5, “Deciding Where to Install the WebAccess Agent and Its MTA,” on page 321 
¢ Section 39.2.6, “Planning the MTA Installation,” on page 322 
+ Section 39.2.7, “Planning the WebAccess Installation,” on page 322 


Setting Up Your Web Server in the Microsoft Cluster 


Before you install WebAccess, your Web server must already be set up and running in the cluster. 
Make sure that it can fail over and fail back successfully. 


As you set up your Web server, record the following key configuration information on the 
WebAccess Clustering Worksheet: 


WEBACCESS CLUSTERING WORKSHEET 


Under Item 7: Physical Web Servers, list the nodes in the cluster where you are installing the Web 
server software. 


Under Item 8: Web Server IP Address, record the secondary IP address of the Web server resource 
that you create. 


Under Item 9: Hardware Virtual Server Information, record the dedicated IP address for the Web site 
and the document root directory. 


Because the WebAccess Application is installed to a subdirectory of the Web server installation 
directory (directory\com\novell\webaccess), the WebAccess Application cannot be installed on a 
shared disk. Instead, you will install it to each node in the cluster where the Web server has been 
installed. 


Planning a New Domain for the WebAccess Agent 


The considerations involved in planning a domain for the WebAccess Agent are much the same as 
planning any other domain. In preparation, review “Planning a New Domain”, then print and fill out 
the “Domain Worksheet” in “Domains” in the GroupWise 8 Administration Guide. 


Keep in mind the following cluster-specific details: 


+ When you specify the location for the domain directory on the Domain Worksheet, include the 
physical disk in your shared disk system where you want the domain directory to be located. 


+ Do not concern yourself with the GroupWise agent information on the Domain Worksheet. You 
can stop with item 10. You will plan the MTA installation later. 


When you have completed the Domain Worksheet, transfer the key information from the Domain 
Worksheet to the WebAccess Clustering Worksheet. 
WEBACCESS CLUSTERING WORKSHEET 


Under Item 1: Resource Group for WebAccess Agent, transfer the shared disk from the Domain 
Worksheet to the WebAccess Clustering Worksheet. 


Under Item 2: WebAccess Agent Domain Name, transfer the domain name and directory from the 
Domain Worksheet to the WebAccess Clustering Worksheet. 
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39.2.3 


39.2.4 


39.2.5 


Planning the WebAccess Resource Group 


The WebAccess resource group is similar to the domain and post office resource groups you have 
already set up, as described in Section 36.5, “Planning GroupWise Resource Groups,” on page 286 
and “Creating GroupWise Resource Groups” on page 299. The WebAccess resource group contains a 
domain whose only role is to connect the WebAccess Agent into your clustered GroupWise system. It 
also contains two agent service resources, one for the MTA that services the domain and one for the 
WebAccess Agent. 


WEBACCESS CLUSTERING WORKSHEET 


Under Item 1: Resource Group for WebAccess, specify the network name and other required 
information for the WebAccess resource group. 


To ensure successful short name resolution, add entries for the WebAccess network name to support 
your preferred methods of short name resolution, as described in “Configuring Short Name 
Resolution” on page 300. 


Planning Cluster-Unique Port Numbers for the WebAccess Agent and 
Its MTA 


As with the MTA and the POA, the WebAccess Agent needs cluster-unique port numbers. As part of 
planning to install the MTA and POA, you should already have determined the IP address and 
cluster-unique port numbers for the WebAccess Agent and its MTA as you filled out the “Network 
Address Worksheet” on page 296. If you do not have a filled-out copy of this worksheet for your 
system, print it now and fill in current system information. 


WEBACCESS CLUSTERING WORKSHEET 


Under Item 1: Resource Group for WebAccess, transfer the WebAccess resource group IP address. 


Under Item 4: MTA Network Information, transfer the cluster-unique MTA port numbers from the 
WebAccess section of the Network Address Worksheet to the WebAccess Clustering Worksheet. 


Under Item 6: WebAccess Agent Network Information, transfer the cluster-unique WebAccess Agent 
port number from the WebAccess section of the Network Address Worksheet to the WebAccess 
Clustering Worksheet. 


Deciding Where to Install the WebAccess Agent and Its MTA 


As with the MTA and the POA, you can choose to install the WebAccess Agent and its MTA to each 
node in the cluster or to the shared disk of the WebAccess resource group. For a discussion of these 
alternatives, see “Deciding Where to Install the Agent Software” on page 291, which describes the 
issues in the context of planning MTA and POA installations. 


WEBACCESS CLUSTERING WORKSHEET 
Under Item 3: MTA Installation Location and Item 5: WebAccess Agent Installation Location, mark 


whether you will install the WebAccess Agent and its MTA to each node in the cluster or to the shared 
disk of the WebAccess resource group. Also specify where the MTA startup file will be stored. 
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39.2.6 


39.2.7 


Planning the MTA Installation 


Follow the instructions in “Planning the MTA Installation” on page 322, then return to this point. 
After you follow the instructions, you will have a filled-out Windows Agent Worksheet to use when 
you install the MTA. 





IMPORTANT: Do not install the Windows MTA until you are instructed to do so in Section 39.3, 
“Setting Up WebAccess in a Cluster,” on page 323. 





Planning the WebAccess Installation 


Aside from the cluster-specific issues discussed in the preceding sections, the considerations 
involved in planning to install WebAccess are the same in a clustering environment as for any other 
environment. Review “Planning GroupWise WebAccess”, then print and fill out the “GroupWise 
WebAccess Installation Summary Sheets” in “Installing GroupWise WebAccess” in the GroupWise 8 
Installation Guide. When you set up WebAccess in a cluster, you will install the WebAccess Agent and 
the WebAccess Application in two separate steps: 


¢ “Planning the WebAccess Agent Installation” on page 322 
¢ “Planning the WebAccess Application Installation” on page 322 





IMPORTANT: Do not install the WebAccess software until you are instructed to do so in 
Section 39.3, “Setting Up WebAccess in a Cluster,” on page 323. 





Planning the WebAccess Agent Installation 


For the WebAccess Agent, fill out items 2 through 12 on the GroupWise WebAccess Installation 
Worksheet, taking into account the following cluster-specific issues: 


WEBACCESS INSTALLATION WORKSHEET 


Under Server Information: Installation Directory, take into account your decision recorded on the 
WebAccess Clustering Worksheet (Item 5: WebAccess Agent Installation Location). 


Under Server Address, transfer the IP address and port number from the WebAccess Clustering 
Worksheet (Item 6: WebAccess Agent Network Information) filled out in “Planning Cluster-Unique Port 
Numbers for the WebAccess Agent and Its MTA” on page 321. 


Under Gateway Directory: Domain Directory Path, transfer the domain directory from the Domain 
Worksheet you filled out in “Planning a New Domain for the WebAccess Agent” on page 320. 


Planning the WebAccess Application Installation 


For the WebAccess Application, fill out items 13 through 19 on the GroupWise WebAccess 
Installation Worksheet, taking into account the following cluster-specific issues: 


WEBACCESS INSTALLATION WORKSHEET 


Under Web Server Information, mark the Web server you have installed in your cluster and specify 
the Web server root directory. Also, specify a directory on the Web server where you want to install 
the WebAccess Agent configuration file. the default is c: \novell. 
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39.3 


39.3.1 


39.3.2 


39.3.3 


Setting Up WebAccess in a Cluster 


You should already have reviewed “Planning GroupWise in a Microsoft Cluster” on page 283 and 
filled out the Section 39.5, “WebAccess Clustering Worksheet,” on page 328. You are now ready to 
complete the following tasks to set up the WebAccess Agent in a clustering environment: 

+ Section 39.3.1, “Setting Up the WebAccess Resource Group,” on page 323 

+ Section 39.3.2, “Creating a Domain for the WebAccess Agent,” on page 323 

+ Section 39.3.3, “Installing the MTA for the WebAccess Agent Domain,” on page 323 

+ Section 39.3.4, “Installing the WebAccess Agent in a Cluster,” on page 324 

+ Section 39.3.5, “Installing and Configuring the WebAccess Application in a Cluster,” on page 324 

+ Section 39.3.6, “Testing Your Clustered WebAccess Installation,” on page 325 


Setting Up the WebAccess Resource Group 


1 Create the WebAccess resource group and agent services resources (WebAccess Clustering 
Worksheet item 1), as planned in “Planning the WebAccess Resource Group” on page 321. 


2 To ensure successful short name resolution, add entries for the WebAccess Agent network name 
to support your preferred methods of short name resolution, as described in “Configuring Short 
Name Resolution” on page 300. 


3 Continue with Creating a Domain for the WebAccess Agent. 


Creating a Domain for the WebAccess Agent 


The WebAccess Agent domain will be a secondary domain. To create it, follow the instructions in 
Section 37.3, “Creating a New Secondary Domain in a Cluster,” on page 301, taking your information 
from the WebAccess Clustering Worksheet, rather than the System Clustering Worksheet, then return 
to this point. 


Do not create any post offices in the WebAccess Agent domain. 


Continue with Installing the MTA for the WebAccess Agent Domain. 


Installing the MTA for the WebAccess Agent Domain 


The MTA for the WebAccess Agent domain can be installed just like any other MTA in your clustered 
GroupWise system. Follow the instructions in “Installing the Agent Software in a Cluster” on 
page 304, then return to this point. 


You do not need to edit the MTA startup file. 


Continue with Installing the WebAccess Agent in a Cluster. 
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39.3.4 


39.3.5 


Installing the WebAccess Agent in a Cluster 


After you have created a domain for the WebAccess Agent and installed the MTA for that domain, 
you are ready to install and configure the WebAccess Agent. The WebAccess Agent is the component 
of your WebAccess installation that accesses post offices and libraries to retrieve information for 
WebAccess client users. 


1 


Map a drive to the shared disk of the WebAccess resource group (WebAccess Clustering 
Worksheet item 1). 


Map a drive to c: \ on the first node in the cluster where you will set up the WebAccess Agent as 
a Windows service (System Clustering Worksheet item 2). 


If you plan to install the WebAccess Agent software to the shared disk of the WebAccess 
resource group (WebAccess Clustering Worksheet item 5), create the drive: \grpwise\webacc 
directory on the WebAccess shared disk accessed in Step 1. 


or 


If you plan to install the WebAccess Agent software to each node in the cluster, create the 
c:\grpwise\webacc directory on the drive accessed in Step 2. 


Start the WebAccess Installation program, following the steps provided in “Installing the 
WebAccess Agent” in “Installing GroupWise WebAccess” in the GroupWise 8 Installation Guide. 


Install the Windows WebAccess Agent, keeping in mind the following cluster-specific details: 
+ On the Components page select only GroupWise WebAccess Agent. 
Do not install the WebAccess Application at this time. 


+ Use items 2 through 12 on the GroupWise WebAccess Installation Worksheet that you filled 
out in “Planning the WebAccess Installation” on page 322 to fill in the fields during the 
WebAccess Agent installation process. 


+ On the Installation Path page, be sure to browse through the mapped drive to the 
installation directory you created in Step 3 above. 


+ On the Gateway Directory page, be sure to browse to the domain directory through the 
drive you mapped in Step 1 above. 


¢ On the Execution Options page, be sure that Run WebAccess Agent as a Windows Service is 
selected. 


+ On the Start Applications page, deselect Start the GroupWise WebAccess Agent. 
Repeat Step 4 and Step 5, mapping a drive to each node in the cluster. 


Even if you installed the WebAccess Agent software to a shared disk, you need to repeat the 
installation process for each node so that the Internet Agent gets set up as a Windows service on 
each node. 


Make sure you have completed all the WebAccess Agent tasks described in “NetWare and 
Windows: Setting Up GroupWise WebAccess” in “Installing GroupWise WebAccess” in the 
GroupWise 8 Installation Guide, but do not start the WebAccess Agent at this time. 


Continue with Installing and Configuring the WebAccess Application in a Cluster. 


Installing and Configuring the WebAccess Application in a Cluster 


Recall that the WebAccess Agent is the component of your WebAccess installation that accesses post 
offices and libraries to retrieve information for WebAccess client users. The WebAccess Application 
provides the link between the WebAccess Agent and the WebAccess clients’ Web browsers. 
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To install the WebAccess Application: 
1 Map a drive to the shared disk of the WebAccess resource group (WebAccess Clustering 
Worksheet item 1) where the WebAccess domain is located. 


2 Map a drive to the first Web server node where you want to install the WebAccess Application 
(WebAccess Clustering Worksheet item 7). 


3 Ifthe Web server node where you are going to install the WebAccess Application is currently 
running any applications that rely on Java or on the Web server, migrate those applications to 
another node in the cluster. If any GroupWise agents are running on the node, migrate the 
agents. 


4 Stop the Web server. 


5 Start the WebAccess Installation program as you did when you installed the WebAccess Agent 
(Step 5 on page 324). Keep in mind the following cluster-specific details: 


+ On the Components page, select only GroupWise WebAccess Application. 


+ Use items 13 through 19 on the GroupWise WebAccess Installation Worksheet that you 
filled out in “Planning the WebAccess Installation” on page 322 to fill in the fields during 
the WebAccess Application installation process. 


+ On the Gateway Directory page, be sure to browse to the WebAccess gateway directory 
(domain\wpgate\webac80a) through the drive you mapped in Step 1 above. 


+ On the Web Server Information page be sure to browse to the Web server root directory 
through the drive you mapped in Step 2 above. 


+ On the Start Applications page, deselect Restart Web Server. 


6 Make sure you have completed all the WebAccess Application tasks described in “NetWare and 
Windows: Setting Up GroupWise WebAccess” in “Installing GroupWise WebAccess” in the 
GroupWise 8 Installation Guide. 


7 Copy the directory\docs\com directory from the server where you just installed the 
WebAccess Application to the document root directory of the Web server. 


8 Restart the Web server. 
9 Offline and then online the Web server to reestablish its resource group IP address. 


10 Repeat Step 2 through Step 9 for each Web server node in the Web server resource group 
possible owners list (WebAccess Clustering Worksheet item 1). 


11 Continue with Testing Your Clustered WebAccess Installation. 


39.3.6 Testing Your Clustered WebAccess Installation 


Remember that the WebAccess resource group and the Web server resource group are separate 
resource groups that could fail over to different nodes at different times. 


To thoroughly test your WebAccess installation: 
1 Make sure the initial combination of WebAccess resource group and Web server resource group 
is functioning properly. 


2 Migrate the WebAccess resource group to each node in its possible owners list, making sure it 
functions with the initial Web server node. 


3 Migrate the Web server to a different node, migrate the WebAccess resource group to each node 
in its possible owners list, then make sure each combination works. 


4 Repeat Step 3 for each Web server resource group. 


5 Continue with Managing WebAccess in a Cluster. 
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39.4 Managing WebAccess in a Cluster 


After you have installed WebAccess in a cluster, you should consider some long-term management 
issues. 
¢ Section 39.4.1, “Updating GroupWise Objects with Cluster-Specific Descriptions,” on page 326 
+ Section 39.4.2, “Knowing What to Expect in WebAccess Failover Situations,” on page 327 
+ Section 39.4.3, “Updating the WebAccess Agent Configuration File (commegr.cfg),” on page 327 


39.4.1 Updating GroupWise Objects with Cluster-Specific Descriptions 


After installing WebAccess in your clustered GroupWise system, while the cluster-specific 
information is fresh in your mind, you should record that cluster-specific information as part of the 
GroupWise objects in ConsoleOne so that you can easily refer to it later. Be sure to update the 
information recorded in the GroupWise objects if the configuration of your system changes. 


+ “Recording Cluster-Specific Information about the WebAccess Agent Domain and Its MTA” on 
page 326 
¢ “Recording Cluster-Specific Information about the WebAccess Agent” on page 326 


Recording Cluster-Specific Information about the WebAccess Agent Domain and 
Its MTA 


To permanently record important cluster-specific information for the WebAccess Agent domain: 


1 In ConsoleOne, browse to and right-click the Domain object, then click Properties. 


2 Inthe Description field of the WebAccess Agent domain Identification page, provide a cluster- 
specific description of the WebAccess Agent domain, including the resource group IP address 
and the cluster-unique port numbers used by its MTA. 


You might also want to include cluster-specific information about the WebAccess Application, 
such as the resource group IP address of the Web server where the WebAccess Application is 
installed. 


Click OK to save the WebAccess domain description. 
Select the WebAccess Domain object to display its contents. 
Right-click the MTA object, then click Properties. 


In the Description field of the MTA Identification page, record the WebAccess resource group IP 
address and the cluster-unique port numbers used by the MTA. 


on F&F OQ 


This information appears on the MTA console, no matter which node in the cluster it is currently 
running on. 


7 Click OK to save the MTA description. 


8 Continue with Recording Cluster-Specific Information about the WebAccess Agent. 


Recording Cluster-Specific Information about the WebAccess Agent 


With the contents of the WebAccess domain still displayed: 


1 Right-click the WEBAC80A object, then click Properties. 
2 Click GroupWise > Identification. 
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39.4.2 


39.4.3 


3 Inthe Description field, record the WebAccess resource group IP address and the cluster-unique 
port numbers used by the WebAccess Agent. 


This information appears on the WebAccess Agent console, no matter which node in the cluster 
it is currently running on. 


4 Click OK to save the WebAccess Agent information. 
5 Continue with Knowing What to Expect in WebAccess Failover Situations. 


Knowing What to Expect in WebAccess Failover Situations 


The failover behavior of the MTA for the WebAccess domain is the same as for an MTA in a regular 
domain. See “Knowing What to Expect in MTA and POA Failover Situations” on page 308. 


The WebAccess Application caches users’ credentials on the node where it is running. Therefore, if 
that node fails, or if the WebAccess Application migrates to a different node, the cached credentials 
are lost. Consequently, the user needs to restart the WebAccess client in order to re-authenticate and 
re-establish the credentials. 


If the WebAccess Agent fails over or migrates, the user receives an error message that the WebAccess 
Agent is no longer available. However, after the WebAccess Agent starts in its new location, the 
WebAccess Application passes the cached user credentials to the WebAccess Agent and the user 
reconnects automatically without having to re-authenticate. 


As with the MTA and the POA, migration of the WebAccess Agent takes longer than failover. 
However, the WebAccess Agent restarts quickly so that users are able to reconnect quickly. 


Updating the WebAccess Agent Configuration File (commgr.cfg) 


As part of installing WebAccess, the WebAccess Agent configuration file (commgr . cfg) is created in 
the following subdirectory: 


domain\wpgate\webac80a 
It is also automatically copied to the following Web server subdirectory: 
drive: \novell\webaccess 


If you change WebAccess agent configuration information (for example, if you change its IP address), 
the information is changed in the following file: 


domain\wpgate\webac80a\commgr.cfg 
because the domain is on the shared disk of a resource group, and it is changed in the following file: 
drive: \novell\webaccess\commgr.cfg 


on the node where the WebAccess Application is currently running. However, the other nodes in the 
Web server possible owners list are not currently available for update. Therefore, you must manually 
copy the updated commgr . cfg file to the drive: \novell\webaccess subdirectory on each node in 
the Web serve possible owners list. 
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Item 


1) Resource Group for 
WebAccess Agent: 


Group name: 

Network name: 

IP address: 

Shared disk: 

Share name: 

MTA service resource: 


WebAccess Agent service 
resource: 


Possible owners 


2) WebAccess Agent Domain 
Name: 


Domain Directory: 


3) MTA Installation Location: 
+ Shared disk of WebAccess 
resource group 
+ Each node in the cluster 
Consolidate MTA startup 
files? 


4) MTA Network Information: 


MTA IP address: 

MTA message transfer port: 
MTA live remote port: 

MTA HTTP port: 


5) WebAccess Agent Installation 
Location: 


+ Shared disk of WebAccess 
resource group 


+ Each node in the cluster 


6) WebAccess Agent 
Network Information: 


WebAccess Agent IP address: 
WebAccess Agent HTTP port: 
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WebAccess Clustering Worksheet 


Explanation 


Specify the information for the WebAccess resource group. 


For more information, see “Planning the WebAccess Resource 
Group” on page 321. 


Specify a unique name for the WebAccess Agent domain. Specify the 
directory on the WebAccess Agent resource group disk where you 
want to create the new domain. 


For more information, see “Planning a New Domain for the 
WebAccess Agent” on page 320. 


Mark the location where you will install the MTA software. 


If necessary, specify the location where you will consolidate the MTA 
startup files on the shared disk of the WebAccess resource group. 


For more information, see “Deciding Where to Install the WebAccess 
Agent and Its MTA” on page 321. 


Gather the MTA network address information from the WebAccess 
section of the “Network Address Worksheet” on page 296. 


For more information, see “Planning Cluster-Unique Port Numbers for 
the WebAccess Agent and Its MTA” on page 321. 


Mark the location where you will install the WebAccess Agent 
software. 


For more information, see “Deciding Where to Install the WebAccess 
Agent and Its MTA” on page 321. 


Gather the WebAccess Agent network address information from the 
WebAccess section of the “Network Address Worksheet” on 
page 296. 


For more information, see “Planning Cluster-Unique Port Numbers for 
the WebAccess Agent and Its MTA” on page 321. 


Item 


7) Physical Web Servers: 


8) Web Server 
IP Address: 


9) Hardware Virtual Server 
Information: 


+ Dedicated IP address: 


+ Document root 


Explanation 


List the servers in the cluster where you are installing the Web server 
for use with WebAccess. 


For more information, see “Setting Up Your Web Server in the 
Microsoft Cluster” on page 320. 


Record the secondary IP address for the Web server in the cluster. 


For more information, see “Setting Up Your Web Server in the 
Microsoft Cluster” on page 320. 


Record the hardware virtual server information for your shared disk 
system. 


For more information, see “Setting Up Your Web Server in the 
Microsoft Cluster” on page 320. 
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Implementing GroupWise Gateways ina 
Microsoft Cluster 


A significant system configuration difference between a GroupWise system in a clustering 
environment and a GroupWise system in a regular environment is that you need to create a separate 
domain to house each GroupWise gateway. The gateway domain should be created in its own 
resource group. This enables the gateway to fail over independently from other GroupWise 
components. 


If you have set up the Internet Agent or WebAccess in your clustered GroupWise system, you should 
already have the skills necessary to set up a GroupWise gateway as well. 


GroupWise gateways that have not received recent development have not been thoroughly tested in 
a clustering environment. If you are currently using such GroupWise gateways, you might want to 
leave them outside of your cluster. 
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Monitoring a GroupWise System ina 
Microsoft Cluster 


GroupWise Monitor is similar to WebAccess in that it relies on a Web server for communication with 
administrators’ Web browsers. Consequently, the setup procedure for GroupWise Monitor in a 
Microsoft cluster is similar to the setup procedure for WebAccess. If you have set up WebAccess in 
your clustered GroupWise system, you should already have the skills necessary to set up GroupWise 
Monitor as well. 


When you first install Monitor, it gathers information about agents to monitor from a domain 
database (wpdomain.db). This provides the resource group IP address of each agent. When an agent 
fails over or migrates to a different node, its status in Monitor displays as Not Listening until it is up 
and running again, at which time its status returns to Normal. 


Because Monitor must use resource group IP addresses to monitor the agents in a clustered 
GroupWise system, the Discover Machine and Discover Network options do not work in a cluster. 
Resource group IP addresses cannot be obtained by examining the network itself. If you need to add 
agents to monitor, use the Add Agent option and provide the agent’s resource group IP address. 


For instructions on setting up GroupWise Monitor, see “Installing GroupWise Monitor” in the 
GroupWise 8 Installation Guide. 
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Backing Up a GroupWise System ina 
Microsoft Cluster 


The issues involved in backing up a GroupWise system in a Microsoft cluster are the same as in 
backing up any GroupWise system that is running on Windows. If you want to back up your 
GroupWise system while it is running, you must use backup software that can back up open files. If 
your backup software cannot back up open files, then you must stop all GroupWise agents before 
running the backup and start them again when the backup is finished. This means that GroupWise 
users cannot be logged into their mailboxes while backups are running. 


To find backup software that is compatible with GroupWise, see the Novell Partner Product Guide 
(http://www.novell.com/partnerguide). 
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Moving an Existing GroupWise 8 System 
into a Microsoft Cluster 


If you are adding the high availability benefits of a Microsoft cluster to a GroupWise 8 system that is 
already up and running, the first step is to set up the cluster and review Chapter 35, “Introduction to 
GroupWise 8 and Microsoft Clusters,” on page 281 to help you apply clustering principles and 
practices to your GroupWise system. 


You do not need to transfer your entire GroupWise system into the cluster all at once. You could 
transfer individual post offices where the needs for high availability are greatest. You could transfer a 
domain and all of its post offices at the same time. You might decide that you don’t need to have all of 
your GroupWise system running in the cluster. 


This section provides a checklist to help you get started with moving your GroupWise system into a 
Microsoft cluster: 


O Decide which shared disks you will use for GroupWise administration (ConsoleOne and the 
software distribution directory). 


O Decide which shared disks you will use for GroupWise domains and post offices. 
C Plan the resource groups for domains and post offices. 


O Review Chapter 36, “Planning GroupWise in a Microsoft Cluster,” on page 283. Fill out the 
“System Clustering Worksheet” on page 294 to help you decide which domains and post offices 
you will move to which shared disks. 


O Review “Planning Cluster-Unique Port Numbers for Agents in the Cluster” on page 289 and fill 
out the “Network Address Worksheet” on page 296 to record resource group IP addresses and 
to specify cluster-specific port numbers for all of your GroupWise agents. 


C Select the first shared disk that will be part of your clustered GroupWise system and set up the 
resource group for it, following the instructions in “Creating GroupWise Resource Groups” on 
page 299 and “Configuring Short Name Resolution” on page 300. 


O Move a domain and/or post office onto the shared disk, following the instructions in “Moving a 
Domain” in “Domains” or “Moving a Post Office” in “Post Offices” in the GroupWise 8 
Administration Guide. 


O Review Section 36.8, “Deciding How to Install and Configure the Agents in a Cluster,” on 
page 289, fill out the “Agent Clustering Worksheet” on page 297, and install the agents as needed 
for the first clustered domain and/or post office, following the instructions in Section 37.5, 
“Installing and Configuring the MTA and the POA in a Cluster,” on page 304. 


C Test the first component of your clustered GroupWise system following the instructions in 
Section 37.6, “Testing Your Clustered GroupWise System,” on page 306. 


O Take care of the cluster management details described in Section 37.7, “Managing Your 
Clustered GroupWise System,” on page 306. 
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O Move more domains and post offices into the cluster as needed. If you have GroupWise libraries, 
see Section 36.4, “Planning a New Library for a Clustered Post Office,” on page 286. 


O Move GroupWise administration into the cluster as needed. 


O Add other components to your clustered GroupWise system as needed, following the 
instructions in: 


¢ Chapter 38, “Implementing the Internet Agent in a Microsoft Cluster,” on page 309 

+ Chapter 39, “Implementing WebAccess in a Microsoft Cluster,” on page 319. 

¢ Chapter 40, “Implementing GroupWise Gateways in a Microsoft Cluster,” on page 331 
+ Chapter 41, “Monitoring a GroupWise System in a Microsoft Cluster,” on page 333 

+ Chapter 42, “Backing Up a GroupWise System in a Microsoft Cluster,” on page 335 
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44,1 


44.1.1 


44.1.2 


Implementing Messenger in a Microsoft 
Cluster 


Novell Messenger does not require the existence of a GroupWise system in your Microsoft cluster, 
but presumably one has already been set up as described in Chapter 36, “Planning GroupWise in a 
Microsoft Cluster,” on page 283 and Chapter 37, “Setting Up a Domain and Post Office in a Microsoft 
Cluster,” on page 299. As part of the process of setting up GroupWise in your cluster, you filled out 
the “System Clustering Worksheet” on page 294. Some of the information from this worksheet will be 
helpful as you implement Messenger in your cluster. 


¢ Section 44.1, “Planning Your Messenger System in a Cluster,” on page 339 


è Section 44.2, “Setting Up Your Messenger System in a Cluster,” on page 342 
+ Section 44.3, “Messenger Clustering Worksheet,” on page 343 


Planning Your Messenger System in a Cluster 


Because the Messenger agents are not associated with GroupWise domains or post offices, the 
Messenger agents are easier to implement in a cluster than are the GroupWise agents. Section 44.3, 
“Messenger Clustering Worksheet,” on page 343 lists all the information you need as you set up the 
Messenger agents in a clustering environment. You should print the worksheet and fill it out as you 
complete the tasks listed below: 


¢ Section 44.1.1, “Understanding Your Cluster,” on page 339 

+ Section 44.1.2, “Planning Messenger Administration,” on page 339 

+ Section 44.1.3, “Deciding Where to Install the Messenger Agent Software,” on page 340 
+ Section 44.1.4, “Planning the Messenger Agent Installation,” on page 341 


Understanding Your Cluster 


Fill out items 1 and 2 in Section 44.3, “Messenger Clustering Worksheet,” on page 343 with 
information about your cluster. This information corresponds to items 1 and 2 on the “System 
Clustering Worksheet” on page 294 that you filled out for GroupWise. For background information, 
see Section 36.1, “Setting Up Your Microsoft Cluster,” on page 284. 


Planning Messenger Administration 


If you have set up a shared disk for GroupWise administration, as described in Section 36.6, 

“Planning Shared Administrative Resources,” on page 287, you can use the same shared disk for the 
Messenger administration files. For example, you might want to have a shared disk where you install 
the Messenger snap-in to ConsoleOne instead of installing it to multiple administrator workstations. 
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MESSENGER CLUSTERING WORKSHEET 


Under Item 5: Installation Location for Messenger Administration, mark whether you want to install 
the Messenger snap-in to ConsoleOne to administrator workstations or to a shared disk. 


If you plan to install the Messenger snap-in to ConsoleOne to a shared disk, under Item 6: Resource 
for Messenger Administration, list the network name and IP address of the shared disk, the physical 
disk name and file share for mapping to it, and the nodes in the cluster that it could fail over to. 


Deciding Where to Install the Messenger Agent Software 


In a Microsoft cluster, the Messenger agents must run as Windows services. When you install the 
Windows Messenger Agents, you can choose between two different installation locations: 


Table 44-1 Messenger Agent Software Installation Locations 


Location Description 

Each node in the The c: \novell1\nm directory is the default installation location provided by the 
cluster Messenger Installation program. 

Shared disk If you create a drive: \novell1\nm directory on a shared disk, the Messenger 


agent software and startup files fail over and fail back along with supporting files 
such as the Messenger archive. 


IMPORTANT: You must install to a shared disk if you do not want a separate 
Messenger archive to be created on each node where the Archive Agent runs. 
If you do not want to use a shared disk, you should plan to install the Archive 
Agent separately outside the cluster. 


Because the Messenger agents must be installed as Windows services in a Microsoft cluster, you must 
initially run the Messenger Installation program for each node in the cluster so that the Windows 
services for the agents get created, regardless of where you are planning to run the Messenger agents 
from. However, for updates, you need to run the Messenger Installation program only once if you are 
running the Messenger agents from a shared disk. 


MESSENGER CLUSTERING WORKSHEET 


Under Item 3: Installation Location for Messenger Agents, mark whether you want to install the 
Messenger agent software to each node in the cluster or to a shared disk. 


Continue with the planning instructions for the installation location you want to use: 


¢ “Planning the Messenger Agents on Each Node in the Cluster” on page 340 
+ “Planning the Messenger Agents on a Shared Disk” on page 341 


Planning the Messenger Agents on Each Node in the Cluster 


Make sure you have filled out item 2 on the Messenger Clustering Worksheet with a complete list of 
nodes in the cluster where you need to install the Messenger agents. Skip to “Planning the Messenger 
Agent Installation” on page 341. 
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Planning the Messenger Agents on a Shared Disk 


If you do not anticipate a large Messenger archive, you can use one Messenger shared disk. If you 
anticipate archiving a large number of messages so that the Messenger archive grows very large, you 
might want to have a separate Messenger shared disk for the Archive Agent and the archive 
database. The steps in this section cover setting up the Messenger agents on a single shared disk. 


MESSENGER CLUSTERING WORKSHEET 


Under Item 4: Resource Group for Messenger Agents, plan the network name and IP address of the 
resource group, the physical disk and share name for mapping to it, the agent service names, and the 
nodes in the cluster where the Messenger resource group can fail over. 


Continue with Planning the Messenger Agent Installation. 


Planning the Messenger Agent Installation 


Aside from the cluster-specific issues discussed in the preceding sections, the considerations 
involved in planning to install the Messenger agents are the same in a clustering environment as for 
any other environment. Review “Planning Your Novell Messenger System”, then print and fill out 
the “Novell Messenger Worksheet” in “Installing a Novell Messenger System” in the Novell 
Messenger 2.1 Installation Guide. Transfer the following information from the Messenger Clustering 
Worksheet to the Messenger System Worksheet: 


+ For Item 3: Installation Path on the Messenger System Worksheet: 


+ If you are installing the Messenger agents to each node in the cluster, use c: \novel1\nm. 


+ If you are installing the Messenger agents to a shared disk, use drive: \novell\nm where 
drive is the shared disk from Item 4: Resource Group for Messenger Agents on the 
Messenger Clustering Worksheet. 


¢ Under Item 12: Server Address on the Messenger System Worksheet: 


+ If you are installing the Messenger agents to each node in the cluster, use the cluster IP 
address from Item 1: Cluster Identification on the Messenger Clustering Worksheet. 


+ If you are installing the Messenger agents to a shared disk, specify the Messenger resource 
group IP address from Item 4: Resource Group for Messenger Agents on the Messenger 
Clustering Worksheet. 


¢ Under Item 13: Configure Agents for Clustering? on the Messenger System Worksheet, mark No. 
This applies to the Messenger Agents running with Novell Cluster Services, not in a Microsoft 
cluster. 


+ Under Item 14: Admin Configuration on the Messenger System Worksheet: 


¢ If you are installing the Messenger snap-in to ConsoleOne to an administrator workstation, 
use the location where ConsoleOne is already installed (typically 
c:\novell\consoleone\version_number). 


¢ If you are installing the Messenger snap-in to ConsoleOne to a shared disk, use 
drive: \directory, where drive is the shared disk from Item 6: Resource for Messenger 
Administration on the Messenger Clustering Worksheet and directory is typically 
c:\novell\consoleone\version_number. 


Continue with Setting Up Your Messenger System in a Cluster. 


Implementing Messenger in a Microsoft Cluster 341 


44.2 


44.2.1 


44.2.2 


Setting Up Your Messenger System in a Cluster 


You should have already reviewed Section 44.1, “Planning Your Messenger System in a Cluster,” on 
page 339 and filled out Section 44.3, “Messenger Clustering Worksheet,” on page 343 and the “Novell 
Messenger Worksheet” in the Novell Messenger 2.1 Installation Guide. Follow the instructions for the 
installation location you have chosen: 

¢ Section 44.2.1, “Installing the Messenger Agents to Each Node in the Cluster,” on page 342 


+ Section 44.2.2, “Installing the Messenger Agents to a Shared Disk,” on page 342 


Installing the Messenger Agents to Each Node in the Cluster 


1 Follow the steps provided in “Starting the Messenger Installation Program” and “Creating Your 
Messenger System” in “Installing a Novell Messenger System” in the Novell Messenger 2.1 
Installation Guide for each node in the cluster. 


2 After you have installed the software to each node in the cluster, if you selected Yes for 
Consolidate Startup Files? (under Messenger Clustering Worksheet item 3), copy the Messenger 
agent startup files to the planned location on the shared disk, then delete them from the 
c:\novell\nm\ma and c:\novell\nm\aa directories on each node to avoid future confusion. 


3 Make each node in the cluster active to make sure that the Messenger agents start successfully 
on each node. 


4 Continue setting up your Messenger system following the instructions in “What’s Next” in 
“Installing a Novell Messenger System” in the Novell Messenger 2.1 Installation Guide. 


Installing the Messenger Agents to a Shared Disk 


Complete the following tasks to set up your Messenger system on a shared disk: 


+ “Setting Up the Messenger Resource Group” on page 342 
+ “Running the Messenger Installation Program” on page 342 


¢ “Testing the Clustered Messenger Agents” on page 343 


Setting Up the Messenger Resource Group 


1 Create the Messenger resource group and agent services resources (Messenger Clustering 
Worksheet item 4), as planned in “Planning the Messenger Agents on Each Node in the Cluster” 
on page 340. 


2 To ensure successful short name resolution, add entries for the Messenger network name to 
support your preferred methods of short name resolution, as described in “Configuring Short 
Name Resolution” on page 300. 


3 Continue with Running the Messenger Installation Program. 


Running the Messenger Installation Program 


1 If necessary, map a drive to the shared disk for Messenger administration (Messenger Clustering 
worksheet item 6) where you will install the Messenger snap-ins to ConsoleOne. 


2 Map a drive to the shared disk of the Messenger resource group (Messenger Clustering 
Worksheet item 4) where you will install the Messenger agent software. 
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3 Map a drive to c: \ on the first node in the cluster (Messenger Clustering Worksheet item 2) 


where you will set up the Messenger agents as a Windows services. 


4 Start the Messenger Installation program, following the steps provided in “Starting the 
Messenger Installation Program” in “Installing a Novell Messenger System” in the Novell 
Messenger 2.1 Installation Guide. 


5 Install the Windows Messenger agents, keeping in mind the following cluster-specific details: 


+ Use the Novell Messenger System Worksheet that you filled out in “Planning the 
Messenger Agent Installation” on page 109 to fill in the fields during the Messenger 
installation process. 


+ When you specify the Messenger installation directory, be sure to browse to the location 


through the drive mapped in Step 2 above. 


+ When you specify the ConsoleOne directory, be sure to browse to the location through the 


drive mapped in Step 1 above. 
+ On the Setup Complete page, do not select Launch Agents Now. 
6 Repeat Step 4 and Step 5, mapping a drive to each node in the cluster. 


Initially, you need to repeat the installation process for each node so that the Messenger agents 
are set up as Windows services on each node. For updates, you need to install only once to the 


shared disk. 
7 Continue with Testing the Clustered Messenger Agents. 


Testing the Clustered Messenger Agents 


After you have set up the Messenger agents on a shared disk in your Microsoft cluster, you can test 


them by manually bringing the Messenger resource group online and taking it offline again. 


Continue setting up your Messenger system following the instructions in “What’s Next” in 
“Installing a Novell Messenger System” in the Novell Messenger 2.1 Installation Guide. 


Messenger Clustering Worksheet 


Item Explanation 

1) Cluster Identification: Record the name and IP address of your Microsoft cluster. 
Cluster name: For more information, see Section 36.1, “Setting Up Your 
Cluster IP address Microsoft Cluster,” on page 284. 

2) Nodes in Cluster: List the servers that are included in your Microsoft cluster. 


For more information, see Section 36.1, “Setting Up Your 
Microsoft Cluster,” on page 284. 


3) Installation Location for Messenger Mark the location where you will install the Messenger agent 
Agents: software. 


+ Each node in the cluster For more information, see “Deciding Where to Install the 
Consolidate startup files? Messenger Agent Software” on page 340. 


+ Shared disk 
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Item 


4) Resource Group for Messenger 
Agents 


Network name: 

IP address: 

Physical disk: 

File share: 

Messaging Agent service: 
Archive Agent service: 
Possible owners 


5) Installation Location for Messenger 


Administration: 


+ Administrator workstation(s) 
+ Shared disk 


6) Resource for Messenger 
Administration: 


Network name: 
IP address: 
Physical disk: 
File share: 
Possible owners 


7) IP Address Resolution Methods: 


+ eDirectory 
+ hosts file 


* DNS 
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Explanation 


If you plan to install the Messenger agent software to a shared 
disk, provide the information about the shared disk you want to 
use. 


For more information, see “Planning the Messenger Agents on 
a Shared Disk” on page 341. 


Mark the location where you want to install the Messenger 
snap-in to ConsoleOne. 


For more information, see “Planning Messenger 
Administration” on page 339. 


If you want to install the Messenger snap-in to ConsoleOne to 
a shared disk, provide the required information about the 
shared disk you want to use. 


For more information, see Section 36.6, “Planning Shared 
Administrative Resources,” on page 287. 


Mark the short name address resolution methods you want to 
implement to ensure that the UNC paths stored in ConsoleOne 
with network names can be successfully resolved into physical 
network addresses. 


For more information, see Section 36.7, “Ensuring Successful 
Name Resolution for GroupWise Resource Groups,” on 
page 287. 


VI Non-GroupWise E-Mail Clients 


If your users already have a common POP, IMAP, or SOAP e-mail client that comes with Linux or 
Windows, they can continue to use it to access their GroupWise mailboxes. Users of non-GroupWise 
e-mail clients retain the feature sets of their familiar e-mail clients, but many GroupWise features are 
not available to such users because they are not offered in POP, IMAP, and SOAP e-mail clients. For 
example, calendaring is available only if the POP, IMAP, or SOAP client supports iCal. 

¢ Chapter 45, “Outlook Express,” on page 347 

+ Chapter 46, “Microsoft Outlook,” on page 349 


¢ Chapter 47, “Evolution,” on page 351 
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Outlook Express 


The GroupWise Internet Agent is required in order for users to access their mailboxes using non- 
GroupWise clients. If you have not already installed the Internet Agent, follow the instructions in the 
GroupWise 8 Installation Guide. 


In order for users to access their GroupWise mailboxes from a third-party e-mail client, they must 
configure their e-mail clients to access their GroupWise accounts. For example, Outlook Express 
users would follow steps similar to the following: 





NOTE: Steps might vary depending on the versions of Windows and Outlook Express installed on 
the workstation. 





1 In Outlook Express, click Tools > Accounts > Add > Mail. 
2 Follow the prompts and provide personal information until you are prompted for the e-mail 
server information. 


Internet Connection Wizard i x| 


E-mail Server Names 


My incoming mail serverisa |POP3 v| server. 


Incoming mail (POP3, IMAP or HTTP) server: 


DA, o 


An SMTP server is the server that is used for your outgoing e-mail. 


Outgoing mail (SMTP) server: 


a 





< Back Cancel 





3 Select POP3 or IMAP as your incoming mail server type. 


4 Inthe Incoming and Outgoing Mail fields, specify the IP address or hostname of your outgoing 
mail server, then click Next. 


5 Continue following the prompts and providing personal information until the new account has 
been set up in Outlook Express. 


6 Click Tools > Accounts. 


7 Select the new account you just created, then click Properties > Servers. 
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© gwmail.net Properties 2) x) 


General Servers | Connection | Security | Advanced | 





Server Information 


My incoming mail server is a POPs server. 

Incoming mail (POP3}: [gwmailnet 0 

Dutgoing mail (SMTP): [owman 
Incoming Mail Server 

Account name: [tanaka = sts—~—S 

Password: pe 


IV Remember password 
T Log on using Secure Password Authentication 








Outgoing Mail Server 


IV My server requires authentication Settings 





8 Select My Server Requires Authentication, then click OK. 


The default setting for server authentication is Use Same Settings as My Incoming Mail Server, so 
you do not need to change any settings. 


9 To access your GroupWise mailbox in Outlook Express, click Tools > Send and Receive. 
10 Click the IP address or hostname of your mail server. 


11 Provide your username and password, then click OK. 
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Microsoft Outlook 


The GroupWise Internet Agent is required in order for users to access their mailboxes using non- 
GroupWise clients. If you have not already installed the Internet Agent, follow the instructions in the 
GroupWise 8 Installation Guide, available on the GroupWise 8 Documentation Web site (http:// 
www.novell.com/documentation/gw8). 


If your users have been using the Microsoft Outlook e-mail client that comes with Microsoft Office, 
they can continue to use POP or IMAP in it to access their GroupWise mailboxes. 


In order for users to access their GroupWise mailboxes from Outlook, they must configure Windows 
to access their GroupWise accounts. For example, Outlook users would follow steps similar to the 
following. 





NOTE: Steps might vary depending on the versions of Windows and Outlook installed on the 
workstation. 





1 Inthe Windows Control Panel, double-click Mail. 

2 Click Show Profiles > Add to add a new profile for your GroupWise account. 
3 Type a name for the new profile, the click OK. 

4 Select Add a New E-Mail Account, then click Next. 


E-mail Accounts J 21x) 
Server Type 
You can choose the type of server your new e-mail acount will work with. È 


C Microsoft Exchange Server 
Connect to an Exchange server to read e-mail, access public Folders, and 
share documents, 

C POP3 
Connect to a POP3 e-mail server to download 
your e-mail, 

C IMAP 
Connect to an IMAP e-mail server to download e-mail and synchronize 
mailbox folders. 

C HTTP 
Connect to an HTTP e-mail server such as Hotmail to download e-mail and 
synchronize mailbox folders. 

C Additional Server Types 
Connect to another workgroup or 3rd-party mail server, 





5 Select POP3 or IMAP as your incoming mail server type, then click Next. 


Microsoft Outlook 349 


aixi 
Internet E-mail Settings (POP3) iS 
> 


Each of these settings are required to get your e-mail account working. 





User Information Server Information 


Your Name: Incoming mail server (POP3); 
E-mail Address: Outgoing mail server (SMTP): 


Logon Information Test Settings 

User Name: S After Filing out the information on this screen, we 
recommend you test your account by clicking the button 

Password: below. (Requires network connection) 


IV Remember password 





D Log on using Secure Password 
Authentication (SPA) 








Next> Cancel | 





6 Provide the e-mail account settings for the type of server you selected. 
7 Click Test Account Settings to make sure that you have provided the information correctly. 
8 Click Next, then click Finish. 


You can now access your GroupWise mailbox using Microsoft Outlook by selecting the profile you 
just created. 
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Evolution 


Evolution makes the tasks of storing, organizing, and retrieving your personal information easy, so 
you can work and communicate more effectively with others. It’s a highly evolved groupware 
program, an integral part of the Internet-connected desktop. 


Evolution can help you work in a group by handling e-mail, address, and other contact information, 
and one or more calendars. It can do that on one or more computers, connected directly or over a 
network, for one person or for large groups. 


With Evolution, you can accomplish your most common daily tasks quickly. For example, it takes 
only one or two clicks to enter appointment or contact information sent to you by e-mail, or to send e- 
mail to a contact or appointment. People who get lots of e-mail will appreciate advanced features like 
vFolders, which let you save searches as though they were ordinary e-mail folders. 


If you have Evolution 2.4 or later installed, you can access accounts on Novell GroupWise 8. 


+ Section 47.1, “GroupWise Features Available in Evolution,” on page 351 


è Section 47.2, “Configuring Evolution,” on page 352 


47.1 GroupWise Features Available in Evolution 


Evolution connecting to GroupWise supports the following basic GroupWise features: 


e Mail 
+ View mail and folders stored on the GroupWise system. 
+ Send mail from you GroupWise account. 
¢ Convert mail to a task or meeting. 

¢ Calendar 


¢ Send and receive appointment and meeting requests. Allows Evolution users to schedule 
meetings and view attendee availability for other users on GroupWise. 


¢ Receive an iCalendar meeting request and add it to your calendar. It is saved to your 
GroupWise calendar. 


¢ Contacts 


+ Address Completion is supported for your GroupWise address books, including the 
corporate address book, the Frequent Contacts address book, and your personal address 
book. 


¢ Adding vCards to the Address Book. If you receive a vCard attachment and click Save in 
Address Book, it is saved to your Personal address book. New Address Book entries can be 
added to your Personal address book from received e-mail messages with a single click. 


¢ Proxy 
¢ Assign Proxy access to other users. 


¢ View other users’ accounts through Proxy access. 
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47.2 Configuring Evolution 


In order for users to access their GroupWise mailboxes from Evolution, they must configure 
Evolution to access their GroupWise accounts. 


1 Click Edit > Preferences, then click Mail Accounts. 
2 Click Add. 
3 On the Identity page, type your e-mail address, then click Forward. 





r 7 
© Evolution Setup Assistant 


Identity 





Please enter your name and email address below. The 
"optional" fields below do not need to be filled in, unless 
you wish to include this information in email you send. 


Required Information 


Eull Name: [Tabitha Hu | 








Email Address: [thu@Corporate.com | 





Optional Information 
[V] Make this my default account 





Reply-To: | | 








Organization: | | 

















| % Cancel | | @ Back | 














4 On the Receiving Mail page, select Novell GroupWise as your server type. 


5 Type the name of your mail server, your user name, and select whether to use SSL. 
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& Evolution Setup Assistant 


Receiving Mail 





Please enter information about your incoming mail 
server below. If you are not sure, ask your system 
administrator or Internet Service Provider. 





Server Type: | Novell GroupWise I$] 





Description: For accessing Novell Groupwise servers 





Configuration 





Host: some_domain.com | 








Usemame: |thu | 





Security 


Use Secure Connection (SSL): | Whenever Possible | $ 


Authentication Type 





Password E | Check for Supported Types | 





{¥] Remember password 














X Cancel | | @ Back | 














6 Click Forward. 


7 On the Receive Options page, select if you want Evolution to automatically check for new mail. 


If you select this option, you need to specify how often Evolution should check for new 
messages. 


8 Select if you want to check for new messages in all folders. 


14 
15 


Select if you want to apply filters to new messages in the Inbox on the server. 
Select if you want to check new messages for junk content. 

Select if you want to only check for junk messages in the Inbox folder. 

Select if you want to automatically synchronize remote mail locally. 


Type your Post Office Agent SOAP port number in the Post Office Agent SOAP Port field, then 
click Forward. 


If you are unsure of what your Post Office Agent SOAP port number is, contact your system 
administrator. 


On the Account Management page, type the name for the account, then click Forward. 
Click Apply. 
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Mobile Devices 


If you own a mobile device, you can synchronize it with GroupWise. GroupWise has provided 
GroupWise Mobile Server for synchronizing several of the most common device. In addition, 
GroupWise has teamed up with BlackBerry for synchronizing of BlackBerry devices. 


¢ Chapter 48, “Novell Data Synchronizer Mobility Pack,” on page 357 
+e Chapter 49, “BlackBerry Enterprise Server,” on page 359 
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Novell Data Synchronizer Mobility Pack 


Using Novell Data Synchronizer, you can synchronize e-mail and other Personal Information 
Manager (PIM) data from Novell GroupWise to mobile devices. The Mobility Pack includes Data 
Synchronizer, the GroupWise Connector, and the Mobility Connector. Additional connectors can be 
added to a Synchronizer system to synchronizer GroupWise data to other supported applications. 


For more information, see: 


¢ Novell Data Synchronizer documentation Web page (http://www.novell.com/documentation/ 
datasynchronizer1) 


¢ Novell Data Synchronizer Connectors documentation Web page (http://www.novell.com/ 
documentation/datasync_connectors1) 
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BlackBerry Enterprise Server 


Novell and Research In Motion collaborate to deliver stellar support to the thousands of customers 
accessing GroupWise on BlackBerry devices. This partnership has resulted in strong solutions for 
end users and administrators alike. 


The BlackBerry Enterprise Solution provides a complete wireless platform that allows organizations 
to extend the their Novell GroupWise messaging application and other enterprise tools to mobile 
professionals. The BlackBerry Enterprise Solution provides users with mobile access to e-mail, 
instant messaging (IM), calendar, personal information management (PIM) and applications - all 
from a single wireless device. In addition, with BlackBerry push technology, these users are 
automatically sent up-to-date information while they’re on the go. 


BlackBerry Enterprise Server software is an important element of the BlackBerry Enterprise Solution. 
It is designed to provide IT departments with simplified management and centralized control of 
wireless devices in a secure, scalable and flexible architecture. BlackBerry Enterprise Server v.4.1 for 
Novell GroupWise includes several new features to enhance end user productivity and back-end 
administration. These features include Novell Messenger support, enhanced support for PowerPoint 
and Web Doc attachments, group- and role-based administration, localized data pass-through and 
SMS/PIN/call log auditing. 


For more information about BlackBerry Enterprise Server for Novell GroupWise, see the BlackBerry 
Enterprise Server for Novell GroupWise product Web site (http://na.blackberry.com/eng/services/ 
business/server/full/). 


For documentation, see the BlackBerry Enterprise Server for Novell GroupWise product 
documentation Web site (http://docs.blackberry.com/en/admin/subcategories/ 
?userType=2&category=BlackBerry+Enterprise+Servert+for+Novell+Group Wise). 


For GroupWise-specific BlackBerry articles, look up “GroupWise” in the BlackBerry Technical 
Solution Center. (http://na.blackberry.com/eng/support) 


For support information, look up “GroupWise” in the BlackBerry Technical Knowledge Center (http:/ 
/www.blackberry.com/knowledgecenterpublic/livelink.exe). 
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Documentation Updates 


This section lists updates to the GroupWise 8 Interoperability Guide that have been made since the 
initial release of GroupWise 8. The information helps you to keep current on documentation updates 
and, in some cases, software updates (such as a Support Pack release). 


The information is grouped according to the date when the GroupWise 8 Interoperability Guide was 
republished. Within each dated section, the updates are listed by the names of the main table of 
contents sections. 


The GroupWise 8 Interoperability Guide has been updated on the following dates: 


+ Appendix A, “June 26, 2012 (GroupWise 8 SP3),” on page 363 

+ Appendix B, “December 9, 2010 (Compatibility with Vibe OnPrem 3),” on page 365 
+ Appendix C, “July 14, 2010 (GroupWise 8 SP2),” on page 367 

+ Appendix D, “August 31, 2009 (GroupWise 8 SP1),” on page 369 
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June 26, 2012 (GroupWise 8 SP3) 


Location 


Novell Cluster Services on 
Linux 


Part Il, “Novell Cluster Services 
on Linux,” on page 117 


Section 15.1.2, “Selecting the 
Internet Agent Partition and 
Secondary IP Address,” on 
page 154 and “Forcing Use of 
the Internet Agent Secondary IP 
Address” on page 167 


Novell Vibe 


Part Ill, “Novell Vibe,” on 
page 231 


Chapter 24, “Accessing Your 
Vibe Site from the GroupWise 
Client,” on page 237 


Change 


Updated the examples of load and unload scripts for the MTA, POA, and 
GWIA. 


Emphasized the importance of exclusively binding the Internet Agent to the 
secondary IP address on its server. 


Updated for the product name change from Novell Vibe OnPrem to Novell 
Vibe. 


Emphasized that users must provide their GroupWise email address in their 
Vibe profile in order to take advantage of GroupWise/Vibe integration. 
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December 9, 2010 (Compatibility 
with Vibe OnPrem 3) 


Location Change 


Novell Vibe OnPrem 


Part III, “Novell Vibe,” on Updated for the product name change from Novell Teaming to Novell Vibe 
page 231 OnPrem. 
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July 14, 2010 (GroupWise 8 SP2) 


Location Change 


Novell Cluster Services on 
NetWare 


“Modifying the Volume Resource Added a link to a helpful TID. 
Load Script for the Agents” on 
page 48 


“Modifying the Volume Resource Added a link to a helpful TID. 
Load Script for the Internet 
Agent” on page 69 


“Modifying the Volume Resource Added a link to a helpful TID. 
Load Script for the WebAccess 
Agent” on page 87 


Novell Cluster Services on 
Linux 


“Modifying the Cluster Resource Changed the recommended commands for unloading the MTA and POA on 
Unload Script for the Agents” on an NSS volume or in a shared pool. 
page 143 


“Modifying the Cluster Resource Changed the recommended commands for unloading the Internet Agent 
Unload Script for the Internet and its MTA on an NSS volume or in a shared pool. 
Agent and Its MTA” on page 165 


“Modifying the Cluster Resource Changed the recommended commands for unloading the WebAccess 
Unload Script for the WebAccess Agent and its MTA on an NSS volume or in a shared pool. 
Agent and Its MTA” on page 185 


“Modifying the Cluster Resource Changed the recommended commands for unloading the Monitor Agent on 
Unload Script for the Monitor an NSS volume or in a shared pool. 
Agent” on page 202 


Novell Conferencing 


Part IV, “Novell Conferencing,” Updated the documentation links to the new version of Novell Conferencing. 
on page 243 


Novell ZENworks 


Chapter 28, “Using ZENworks 10 Added instructions for installing the GroupWise WIndows client using 
Configuration Management to ZENworks 10 Configuration Management. 

Distribute the GroupWise 

Windows Client,” on page 251 


Section 29.1, “Installing Added instructions for meeting prerequisites when installing the GroupWise 
Supporting Applications,” on Windows client using ZENworks 7 Desktop Management. 
page 257 
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Location Change 


Mobile Devices 


Chapter 48, “Novell Data Replaced the documentation links to GroupWise Mobile Server 
Synchronizer Mobility Pack,” on documentation with links to the Novell Data Synchronizer Mobility Pack 
page 357 documentation. Synchronizer is the next generation of mobile device 


support for GroupWise users. 
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Location Change 


Novell Cluster Services on 


NetWare 

Section 16.1, “Understanding the Emphasized that if you have not clustered your Web server, you can install 
WebAccess Components,” on the WebAccess Application on a Web server that is outside the cluster 
page 175 where the WebAccess Agent is installed. 

Novell Cluster Services on 

Linux 

Chapter 18, “Backing Up a Added information about using the GroupWise Target Service Agent for File 


GroupWise System in a Linux Systems (TSAFSGW) on Linux. 
Cluster,” on page 209 


Microsoft Clustering Services 
on Windows 


Section 36.5, “Planning Explained that multiple Internet Agents or multiple WebAccess Agents 
GroupWise Resource Groups,” cannot run on the same node at the same time. 
on page 286 


Mobile Devices 


Chapter 49, “BlackBerry Added links to BlackBerry documentation and support sites. 
Enterprise Server,” on page 359 
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